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