Thought on cloud-init vs. first boot

[Adam Young]

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 at fedoraproject.org>   escribió:
>>>> El Mon, 05 Mar 2012 14:03:43 -0500
>>>> Adam Young<ayoung at redhat.com>   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