Bug 1254889

<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

(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.

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/

Radek,
we will probably also need a .treeinfo file for these trees.

(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? [1]

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?

[1] 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.

(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? [1]

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.

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

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.

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.