Thought on cloud-init vs. first boot

[Daniel P. Berrange]

On Wed, Mar 07, 2012 at 08:00:34PM -0500, Adam Young wrote:
> On 03/07/2012 12:13 PM, Daniel P. Berrange wrote:
> >On Wed, Mar 07, 2012 at 11:54:05AM -0500, Adam Young wrote:
> >>On 03/06/2012 12:30 PM, Dennis Gilmore wrote:
> >>>El Tue, 6 Mar 2012 11:08:22 -0600
> >>>Dennis Gilmore<ausil at fedoraproject.org>   escribió:
> >>>>El Mon, 05 Mar 2012 14:03:43 -0500
> >>>>Adam Young<ayoung at redhat.com>   escribió:
> >>>>>Dennis,
> >>>>>
> >>>>>Wanted to float this by you first before opening it to a wider
> >>>>>audience.
> >>>>>
> >>>>>For fedora's VM image,  we can add an additional RPM that drops a
> >>>>>firstboot module in with priority -1 (If that is in fact allowed,
> >>>>>other wise priority 0,  and reschedules language to 1) that will
> >>>>>run cloud-init and,  upon success, disable all other firstboot
> >>>>>modules. If it fails,  firstboot runs as per normal.
> >>>>>
> >>>>>What do you think?
> >>>>>
> >>>>>Adam
> >>>>I really don't think it will work, AFAIK cloud-init if it fails will
> >>>>keep trying until it succeeds because the data it needs may not be
> >>>>available initially. We are really too late for F17. putting in a
> >>>>framework to deal with it properly will take some work. I think that
> >>>>maybe a good solution would be to deal with it via a boot time flag.
> >>>>the question then becomes how exactly would it work?
> >>>>
> >>>>Id think something like this.  we add the boot flag to the grub1
> >>>>config which is used by ec2.  grub2 being unaffected. we would
> >>>>then need teach cloud-init which we would need to set with
> >>>>dependencies higher to run before firstboot would see the flag and
> >>>>disable firstboot. now im not 100% sure that we can actually do that.
> >>>>then anyone that deploys the images to an ec2 like environment like
> >>>>eucalyptus would need to make sure they set the flag in their grub2
> >>>>config for deployment.
> >>>>
> >>>>of course a lot of this is all speculation on how it all works. I
> >>>>think for F17 we should make 2 sets of base virt guest images. one
> >>>>that has cloud-init and one that has firstboot. then the user can
> >>>>choose which to grab.
> >>>>
> >>>>Dennis
> >>Agreed that cloud-init and Firstboot won't work together.
> >>
> >>Another thought is that we could modify the live CD image such that
> >>it can better be used as a Virtual Machine.  What we have is fairly
> >>close to that solution already,  so what it would need is:
> >>
> >>1.  An easy way to generate a Persistant store for the /var/ /home
> >>and /tmp directories
> >>2.  An easy way to resize the ISO image to something large enough to
> >>install/update RPMS
> >>
> >>This is obviously a pretty big stretch,  and I wouldn't expect it
> >>could be a F17 task.  It might be the wrong approach, but it would
> >>be worth at least talking through it.
> >>
> >>The EC2 images are pretty much "minimal" installs, right?  I think
> >>that they should continue to be separate from the Fedora appliance
> >>for virtualization anyway. The appliance should be comparable to the
> >>Live CD:  Gnome Desktop and all.
> >I rather disagree here - the appliance images should be JEOS images,
> >exactly like the EC2. For desktop users, the existing Live CD is
> >already a good solution.
> By Desktop,  we mean people running the Hypervisor on their Desktop,
> and importing Fedora Virtual machines.  The Live CD does not support
> that,  as it still requires a full install and reboot to get the VM
> up and running if you want any persistence.

This is a little cumbersome using virt-manager, but with GNOME Boxes this
situation is much simpler. You just point it at the ISO image you have,
and it auto-generates a kickstart file to do a fully automated install of
a desktop system without needing any real interaction on the part of the
user. Via the magic of libosinfo, Boxes will eventually support this for
any modern Linux OS. This is a more flexible approach for desktop usage
than relying on the distro vendor to have provided suitably configured
images IMHO.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|