Re: [pve-devel] [PATCH v3 qemu-server 0/7] cloudinit pending behaviour change

[Fabian Ebner <f.ebner@proxmox.com>]

Am 09.06.21 um 13:54 schrieb Alexandre Derumier:
> Hi,
> 
> This is an attempt to cleanup current behaviour of cloudinit online changes.
> 
> Currently, we setup cloudinit options as pending, until we generate the config drive.
> 
> This is not 100% true, because some option like vm name, nic mac address can be changed,
> without going to pending, so user can't known if it need to regenerated it.
> 
> Also custom config can be done with snippets file, without any pending state.
> 
> Also, some can are very difficult to handle, if you hotplug a nic but it's failing,so pending,
> then you defined an ipconfig, and then you revert hotplug.
> 
> (This will be really usefull with ipam implementation, where ipconfig pending state is really
>  needed, as we need to follow the pending state of the netX interface)
> 
> So, instead of setting cloudinit values in pending,
> this patch serie extract the current config from the cloudinit drive and compare it to vm config (pending config).
> 
> (Currently the vm config is simply copied inside the iso at generation, but we could implemented
>  configdrive format parsers) 
> 
> A new specific cloudinit config api is added too, merging ipaddrX && netX mac
> in same field, and displaying the diff between current and generated config.
> (we could implemented read config from custom snippet too later)
> 
> 
First off all, sorry for the very late review.

The biggest question still is which approach should be used.

Two downsides of this approach:
* The VM config is made available inside the guest via the ISO, but the
guest doesn't really have any business knowing it.
* The extraction is a bit involved/costly. And technically, we'd need to
lock the config during the extraction (so the drive can't be removed
under our noses, and to prohibit two extractions at the same time). And
it's difficult to tell if extraction failed because it's an old image
that doesn't include the config yet, or if it failed for real.

So IMHO the other approach is a bit better. Much of the review should
also apply to v2 of the series.

A small problem with both approaches is how to handle already existing
configs, because everything will show up as changed. Not really sure
what could be done about that though. Ignoring it and having it
auto-fixed the next time the cloud-init is generated doesn't seem too bad.