On Wed, Mar 07, 2012 at 08:00:34PM -0500, Adam Young wrote:
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(a)fedoraproject.org> escribió:
>>>>El Mon, 05 Mar 2012 14:03:43 -0500
>>>>Adam Young<ayoung(a)redhat.com> 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
>>>>>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
>>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.
This is a little cumbersome using virt-manager, but with GNOME Boxes this
situation is much simpler. You just point it at the ISO image you have,
and it auto-generates a kickstart file to do a fully automated install of
a desktop system without needing any real interaction on the part of the
user. Via the magic of libosinfo, Boxes will eventually support this for
any modern Linux OS. This is a more flexible approach for desktop usage
than relying on the distro vendor to have provided suitably configured