Thought on cloud-init vs. first boot

[Adam Young]

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.