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

[DERUMIER, Alexandre]

Hi Fabian,

I'm back from holiday.

I'll rework the v2 patch series with all your comments.


About:

>>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.

Yes, I was thinking about simply wait to next boot for regenerate the
new section.
But maybe I could be possible to not display all changes if the new
[cloudinit] section don't exist yet.



I'll try to send a v4 next week.


Alexandre





Le jeudi 31 mars 2022 à 15:01 +0200, Fabian Ebner a écrit :
> 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.
>