[pve-devel] cloudinit for proxmox 5 v3

[Alexandre DERUMIER]

Hi !


>>@Alexandre: Since some of our changes fixup & build upon each other's 
>>previous patches I'd propose using a 'Co-developed-by' tag in the 
>>commit message for when squashing fixups of one person into another's 
>>commit, would that be okay with you? 

yes sure, no problem!


>>- The config-drive format has a few issues. For one, I couldn't use it 
>>in a VM without forcing its network interface name to match the 
>>config drive's (`eth0`) (and then it completely ignored my DNS 
>>settings). 
>>I wonder if we should switch to the NoCloud variant which seems to 
>>allow matching by mac address (as well as driver or name)? 

For windows, the only current daemon available is
https://cloudbase.it/cloudbase-init/
https://github.com/openstack/cloudbase-init

and it's seem to support only configdrivev2.
http://cloudbase-init.readthedocs.io/en/latest/services.html#openstack-configuration-drive


Maybe should we support 2 kinds of variant ? 1 for linux, 1 for windows ?



----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 19 Février 2018 15:10:29
Objet: Re: [pve-devel] cloudinit for proxmox 5 v3

On Thu, Jul 27, 2017 at 05:06:33PM +0200, Alexandre Derumier wrote: 
> Now that proxmox 5.0 is launched, maybe can we try to target cloudinit for 5.1 ? 

We'd like to move forward with this. I rebased this patch set again 
(available at https://github.com/Blub/pve-qemu-server cloudinit branch). 

There are a few final steps before we can merge this: 
- Since the patch set contains a bunch of fixup-style commits we'd like 
to squash them to create a more easy-to-read (and easier-to-bisect) 
history. 
@Alexandre: Since some of our changes fixup & build upon each other's 
previous patches I'd propose using a 'Co-developed-by' tag in the 
commit message for when squashing fixups of one person into another's 
commit, would that be okay with you? 

- I'm really not a fan of using qemu-nbd here, particularly because in 
my latest tests its been shown to require some additional fsync-work 
(see my latest patch on github inserting a `dd conv=fsync` pipe...). 
There are two options: Since the images are really tiny, we could 
create temporary files in /run for now, and convert those, or, since 
I'm building qemu with a patch for `dd` to accept data from stdin, 
the only thing missing for that to be usable is to make it not return 
an error if the input is too short. 

- The config-drive format has a few issues. For one, I couldn't use it 
in a VM without forcing its network interface name to match the 
config drive's (`eth0`) (and then it completely ignored my DNS 
settings). 
I wonder if we should switch to the NoCloud variant which seems to 
allow matching by mac address (as well as driver or name)?