[pve-devel] RFC: qemu-server : add cloudinit support

[Alexandre DERUMIER]

>>Here's a thought:
>>Maybe in order to reflect this situation the web UI could simply have
>>a (possibly even VM independent?) way of creating and manipulating a
>>config-drive (even if it's just network configuration and maybe a list
>>of ssh-keys), perhaps with a simple counter for an instance ID. And
>>you can attach a config drive from a list similarly to how you attach
>>an ISO image as cdrom (and from the CLI it would be a single option
>>like -configdisk ID, or -configdisk /path/ot/disk).
>>Because it's really more like a support-feature for a guest-feature
>>than providing a general feature on the PVE side.

That's was almost my main idea, have a separate form with 
cloudinit network, sshkey,...

and a checkbox "cloudinit",to enable|disable the generation and mount of the configdrive at start


The main cloud-init usage is really bootstrapping/init the guest the first time.

In my personnal usage I really need it for automation, 
-creating 20-100vm in batch
-setup network
-setup ssh keys
-launch apt-get update
-launch puppet

>From there, I'm using puppet to manage all packages and config inside guest vm (including future network changes)




----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>, "dietmar" <dietmar at proxmox.com>
Envoyé: Vendredi 12 Juin 2015 10:09:06
Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support

> On June 12, 2015 at 9:35 AM Alexandre DERUMIER <aderumier at odiso.com> wrote: 
> dpkg-configure cloud-init , and choose configdrive as only datasource. 
> 
> I think at start, cloud-init ask to his datasources if they are a new config. 

Right, if you can disable this behavior then that's fine. Just need to somewhere 
document that it's recommended to disable all the other unused datasources. 

> >>But if you change the uuid a new directory appears in 
> >>/var/lib/cloud/instances without the old ones disappearing. New files on 
> >>every applied update. 
> >> 
> >>Maybe I'm missing something obvious...? 
> I need to check that, I thinked that only the the symlink 
> /var/lib/cloud/instance ---> /var/lib/cloud/instances/currentuuid/ 
> was applied. 

Applied, yes, but the old directory still exists. The symlink is updated to the 
new one. 

> Maybe this is what about merge is doing ? 
> http://cloudinit.readthedocs.org/en/latest/topics/merging.html 

Perhaps. They only list «#include» as example though. 

So, 
basically, cloud-init does configuration instances which are applied 
only once (but weirdly updated multiple times), and searches all of 
the *guest*'s configured data sources. 

Meaning much of the functionality depends on the guest system, and the 
default configuration of most cloud-init packages is to just test all 
data-sources. 

This situation might need to be reflected in the GUI. If we simply 
have an entry to type in a network configuration etc. there would be 
no guarantee that it's even applied, because whether this will happen 
is the guest's choice. 

Here's a thought: 
Maybe in order to reflect this situation the web UI could simply have 
a (possibly even VM independent?) way of creating and manipulating a 
config-drive (even if it's just network configuration and maybe a list 
of ssh-keys), perhaps with a simple counter for an instance ID. And 
you can attach a config drive from a list similarly to how you attach 
an ISO image as cdrom (and from the CLI it would be a single option 
like -configdisk ID, or -configdisk /path/ot/disk). 
Because it's really more like a support-feature for a guest-feature 
than providing a general feature on the PVE side. 

Thoughts?