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ó: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? AdamI 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.
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud