Re: Thought on cloud-init vs. first boot
On 03/06/2012 12:30 PM, Dennis Gilmore wrote:
El Tue, 6 Mar 2012 11:08:22 -0600
Dennis Gilmore<ausil(a)fedoraproject.org> escribió:
> El Mon, 05 Mar 2012 14:03:43 -0500
> Adam Young<ayoung(a)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.