[Engine-devel] Cloud-Init integration

[Greg Padgett]

On 06/16/2013 05:08 PM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On Thu, Mar 28, 2013 at 07:35:23PM -0400, Greg Padgett wrote:
>>> Hi Everyone,
>>>
>>> I'd like to propose a feature we've been doing some investigation
>>> into, which is to integrate cloud-init support into oVirt.
>>>
>>> Cloud-init is used to help provision new Linux systems by setting
>>> the hostname, ip, ssh keys, timezone, injecting files, and more.
>>> It's used by OpenStack (amongst others) now, and has a lot of
>>> features that may be helpful to our users.
>>>
>>> Details are still evolving, but for more info please see the wiki page:
>>>
>>> http://www.ovirt.org/Features/Cloud-Init_Integration
>>>
>>> All feedback is welcome!
>>
>> All feedback? Even if it's 3 months too late?
 >>

I'll have to be more careful next time to specify a time limit :)  But 
really, thank you both for the comments.  Feel free to add them to a "nice 
to have" list on the wiki page, or I can add it.  Replies inline...

>> If so, then here's a few comments:
>>
>> 1. oVirt-3.2 completely supports IPv6 within guests. It would be nice to
>>     carry this on to cloud-init, by allowing to set the IPv6 address of
>>     the guest. (or are we happy with the auto configured ipv6 addresses?)
>>

It would, but unfortunately cloud-init doesn't yet translate ipv6 fields
from /etc/network/interfaces (its chosen networking input format) to
ifcfg files.  Now that you mention it, it doesn't add IPV6INIT=yes,
either.

These are things we can add--to both oVirt and cloud-init, I guess at a
later time.

>> 2. I think that the GUI used for setting IP addresses should be
>>     immitated here. It allows Static/DHCP/None, and disables the
>>     irrelvant fields when DHCP/None is selected.
>

It's close: there is a checkbox for dhcp, and if selected it will hide the 
non-relevant fields.

> Additionally, you should consider showing the vNIC name and not "eth0" etc.
> IIUC udev rules are rather unpredictable in this regard and could give your
> vNIC a different name on different VM instances (probably by MAC address and/or
> PCI address).
> Either way, I think it's less confusing to refer to the vNIC itself.
>

Similarly to the above, I'm not sure how much cloud-init supports with 
respect to vNICs.  The name is used as the /etc/network/interfaces adapter 
name and the ifcfg-* suffix (per distro), so I guess if you plumbed 
everything around that in the image and could finish the setup with just 
the interfaces/ifcfg config file then it would work as-is.  If that isn't 
adequate (I haven't looked or tested) then we may need to consider 
submitting a patch to add this to cloud-init.

>> 3. Is "Support custom volume label for vm payloads" still on the TODO
>>     list? Note: F19's dosfstools has renamed mkfs.msdos to mkfs.fat.
>>     This means that creating a virtual floppy with a payload currently
>>     does not work there (it's a tiny fix, for sure).
>>

It's implemented.  Of course, it still uses mkfs.msdos.

>> 4. I do not see ovirt-guest-agent mentioned in the feaure page. It is
>>     the obvious channel to report that cloud-init is Done to Engine.
>>

You're right, and this is one part of the feature that hasn't been done. 
It may also require some work on cloud-init, or for us to use a different 
input format (i.e. a mime-formatted sequence instead of vanilla 
config-drive-2).  It would be great to add this, though my time to do that 
now is a bit limited.

>> 5. When we come to implement auto-generate of system ssh key, we may
>>     want to install a virtio-rng device in our VMs, to ensure that the
>>     keys are not too easy to guess. (or create the key in the host and
>>     inject it to the guest)
>

Good idea.  I'm not too familiar with virtio-rng, but if the image can be 
configured to use it then the regeneration should follow suit.  So, not a 
limitation right now but not as easy as it could be.  It's another case of 
needing either a cloud-init patch for support or (I'm thinking more likely 
in this case) some scripting and using a mime-formatted input to cloud-init.

> 6. Is this going to be supported on template/instance type level?
> Probably static IP is not wise on a template, but the other options seem
> like they would be the same for most VMs from the same template/instance.
>

Today it's just on "Run VM Once" but once we can persist the cloud-init 
options I don't see why we wouldn't want to allow persisting at least at 
least some of the fields for templates/instance types.

> 7. Don't forget backwards compatibility considerations for the engine-VDSM
> communication, if you're using APIs that aren't available in older VDSM versions.
>

Thanks, it does rely on some new vdsm API features.

>>
>> Dan.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>