On 03/07/2012 12:13 PM, Daniel P. Berrange wrote:
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.
By Desktop, we mean people running the Hypervisor on their Desktop,
and importing Fedora Virtual machines. The Live CD does not support
that, as it still requires a full install and reboot to get the VM up
and running if you want any persistence.
Daniel
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
