|Summary:||RFE: support Atomic PXE-to-live feature (boot directly into Atomic using PXE, without Anaconda)|
|Product:||[Community] Beaker||Reporter:||Ladislav Jozsa <ljozsa>|
|Status:||NEW ---||QA Contact:||tools-bugs <tools-bugs>|
|Version:||develop||CC:||atodorov, mjia, rvykydal|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Ladislav Jozsa 2015-08-19 07:59:42 UTC
Description of problem: We need to add support of booting live system from PXE in order to test new RHEL Atomic Host feature called PXE-to-Live. Normally, when Beaker attempts to provision system it turns on netboot, PXE boots Anaconda, proceeds with instructions in kickstart and reboots to the installed system. If using PXE-to-Live, there's no Anaconda step involved. Instead of loading Anaconda environment over PXE, whole system is loaded with no reboot after operation completes.
Comment 1 Alexander Todorov 2015-08-19 08:36:40 UTC
<quote> If so it won't work in any sane way with Beaker, because it relies on setting up the host to talk to Beaker in kickstart %post. We would probably need to think up a different way of ensuring the harness container is configured. I guess using cloud-init. </quote> ^^^ from Dan Callaghan
Comment 2 Radek Vykydal 2015-08-19 10:30:35 UTC
(In reply to Alexander Todorov from comment #1) > <quote> > If so it won't work in any sane way with Beaker, because it relies on > setting up the host to talk to Beaker in kickstart %post. We would probably > need to think up a different way of ensuring the harness container is > configured. I guess using cloud-init. > </quote> > > ^^^ from Dan Callaghan I can't come up with anything other then cloud-init now. We might want to use cloud-init also to initialize the Live system but I hope we can find a way of using it for the harness at the same time. If it shows up to be difficult, we may try using VMs with cloud-init iso for harness and cloud-init over http for Live system initialization? Or just let beaker merge user cloud init passed to job with harness stuff? I'd need to look into what the harness container configuration actually does.
Comment 3 Radek Vykydal 2015-08-19 10:32:54 UTC
Here are some details on building and booting Live Atomic from PXE: http://www.projectatomic.io/blog/2015/05/building-and-running-live-atomic/ And nightly Fedora composes: http://atomic-nightly.cloud.fedoraproject.org/composes/2015-08-19/22/Cloud_Atomic/x86_64/pxetolive/
Comment 4 Alexander Todorov 2015-08-19 14:38:16 UTC
Radek, we will probably also need a .treeinfo file for these trees.
Comment 5 Radek Vykydal 2015-08-21 09:11:05 UTC
(In reply to Alexander Todorov from comment #4) > Radek, > we will probably also need a .treeinfo file for these trees. I wonder if we don't want to use something like naked import in this case, seems like there is not much additional valuable information in .treeinfo (ie no repos, variants) If we go with .treeinfo, there are some questions (I am referring to current live atomic build process output: http://atomic-nightly.cloud.fedoraproject.org/composes/2015-08-19/22/Cloud_Atomic/x86_64/pxetolive/ ) 1) what values should it contain? Based on Atomic installer .treeinfo: http://download.eng.blr.redhat.com/pub/rhel/released/atomic/7.1.1/images/installer/lorax/.treeinfo I'd guess something like [general] name = RHEL Atomic Host Live-7 family = RHEL Atomic Host Live timestamp = 1422241798.35 variant =. version = 7 packagedir =. arch = x86_64 [stage2] mainimage = live-rootfs.squashfs.img [images-x86_64] kernel = vmlinuz-4.1.5-200.fc22.x86_64 initrd = initramfs-4.1.5-200.fc22.x86_64.img 2) how or when do we create the file? When building images using Atomic installer iso? Should we take the treeinfo (or relevant parts, timestamp?) from the iso?  3) to boot Live Atomic, ostree= boot argument needs to be supplied (see http://atomic-nightly.cloud.fedoraproject.org/composes/2015-08-19/22/Cloud_Atomic/x86_64/pxetolive/PXE_CONFIG). Should we just let beaker import subclass assume existence of this file and parse it, or rather expose the information explicitly in treeinfo?  Currently we are using the os tree embedded in the iso so live images are bound to particular Atomic installer iso used to create the images, but potentially we might want to use installer iso with some updated remote Atomic tree/repo when building live images so when we want to do an update of Live Atomic (which means building new images) we don't have to compose new installer iso first.
Comment 6 Radek Vykydal 2015-08-21 10:38:25 UTC
(In reply to Radek Vykydal from comment #5) > 2) how or when do we create the file? > > When building images using Atomic installer iso? > > Should we take the treeinfo (or relevant parts, timestamp?) from the iso?  Well, the iso does not contain treeinfo, so it would be added by rel-eng compose tools similarly as it is added to Atomic installer tree I think.
Comment 7 Dan Callaghan 2015-09-08 07:38:08 UTC
It looks like cloud-init has some support for passing through a config on the kernel command line, which is probably the only way we can do it in Beaker: https://github.com/number5/cloud-init/blob/master/doc/sources/kernel-cmdline.txt
Comment 8 Dan Callaghan 2015-09-08 07:40:24 UTC
Oh I just noticed the original blog post linked in comment 3 it seems to be suggesting passing a kernel option like ds=nocloud-net;seedfrom=<url-of-directory> which seems to be another (undocumented?) way of passing in a cloud config from the kernel command line. Not sure which is better.
Comment 9 Dan Callaghan 2015-09-08 07:43:19 UTC
We could add some code to generate a cloud config based on a recipe's install options, the same way we generate a kickstart from templates right now. We already have some code for that written by Matt in /distribution/virt/image-install. Then for Atomic PXE-to-live we would just need to set a kernel option pointing at the Beaker-generated cloud config for that recipe, the same way we set ks= pointing at the recipe's generated kickstart.