Re: Thought on cloud-init vs. first boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 03/06/2012 12:30 PM, Dennis Gilmore wrote:
El Tue, 6 Mar 2012 11:08:22 -0600
Dennis Gilmore<ausil@xxxxxxxxxxxxxxxxx>  escribió:
El Mon, 05 Mar 2012 14:03:43 -0500
Adam Young<ayoung@xxxxxxxxxx>  escribió:

Wanted to float this by you first before opening it to a wider

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?

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.


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.

cloud mailing list

[Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Triage]     [Deep Creek Hot Springs]     [Coolkey]     [Yum Users]     [Tux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux