Implement kernel cmdline and/or autoyast/kickstart support in terraform-provider-libvirt
a project by dmacvicar
a project by dmacvicar
Updated over 1 year ago. 3 hacker ♥️.
terraform-provider-libvirt supports CoreOS ignition file/content, which end rendered as kernel command line options (the provider does some nice stuff like allowing you to pass the json content and it will take care of putting it into a temporary file).
The idea is to:
- Implement a generic CmdLine option, that takes a map (key/value) with the kernel options.
- Implement autoyast/kickstart options, with convenience features eg. inline the content, on top of the generic CmdLine option feature.
- Fri 10.11.2017
- Warm up. Fix local integration tests on openSUSE
- Researching approach:
- can we share code between cloud-init, ignition, autoyast, kickstart?
- how to model common parts? how to abstract differences?
- are provisioner plugins an option? can they inject data to a resource, or just run stuff later?
- Mon 13.11.2017
- Wrote some code for a "install" resource, similar to cloud-init and ignition. Idea would be to merge them somehow later.
- Figured out that I need to upload 3 artifacts to the storage pool: initrd, kernel, profile
- What id to use? Need to recover all volumes later. What about using indirection? eg. one volume with metadata pointing to the volumes with randomly generated names/ids.
- Tue 14.11.2017
- Looking at linuxrc code
- Talked to Steffen. He implemented https://hackweek.suse.com/16/projects/implement-qemu-firmware-config-device-support-in-linuxrc-slash-autoyast already! Implemented the missing part in the linuxrc code.
- Wed 15.11.2017
- False start trying to implement uploading of boot artifacts (kernel, initrd) by uploading metadata to libvirt secrets. It resulted to be limited in size. Bah!. That is what you get when you abuse APIs. Deserved.
- Thu 16.11.2017
- Re-evaluating if it is worth to implement all the virt-install functionality of allowing a install from a url by downloading kernel/initrd and uploading it to a volume. Another alternative is to use the QEMU http backend to directly boot from an ISO.
- Implemented support of remote network disks using QEMU native http
- Start implementing kernel, initrd and cmdline support. That combined with volumes should be enough for a custom boot. Pull Request
This project is part of:
Hack Week 15 Hack Week 16
Uyuni test suite improvements by dgedon
Uyuni is the upstream...
Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil
Join the Gitter channel! [https://gitter.im/uy...
Be the first to comment!