[pve-devel] cloudinit: question about cloudinit pending values && hostname/mac address changes

[aderumier at odiso.com]

Hi,

I just send a small patch, adding a new hotplug option: cloudinit,

to autoregenerate config drive when cloudinit option are updated.

What do you think about it ?  (Like this user can choose the behaviour)

Le mardi 23 février 2021 à 10:29 +0100, Thomas Lamprecht a écrit :
> On 23.02.21 10:06, Wolfgang Bumiller wrote:
> > 
> > > On 02/23/2021 9:27 AM Thomas Lamprecht <t.lamprecht at proxmox.com>
> > > wrote:
> > > 
> > >  
> > > On 21.02.21 18:47, aderumier at odiso.com wrote:
> > > > I have some question about cloudinit hotplug pending values.
> > > > 
> > > > Currently, when vm is running, we keep cloudinit specific
> > > > values
> > > > (ipconfigX, dns, ssh,...)  in pending until we regenerate image
> > > > manually. 
> > > > 
> > > > But some other change, like vm name (use for hostname), or nic
> > > > mac
> > > > address . (use to match interface in config nodrive format),
> > > > are not
> > > > keeped as pending.
> > > > 
> > > > Why don't we simply auto regenerate the cloudinit config drive
> > > > after
> > > > changes? (and don't use pending values like "pending  cdrom
> > > > generation").
> > > 
> > > IMO OK, wasn't the other stuff done because of some changes
> > > cannot be
> > > applied live?
> > 
> > Or maybe just an oversight since the VM name used to have no
> > influence
> > at all before cloud init.
> > I'm not sure if automatically regenerating the image is such a good
> > idea
> > if you consider how programs in the guest might react if they're
> > currently reading from a vanishing drive... (Simply because, you
> > know,
> > these things tend to not be too failure-resistent ;-) )
> 
> normally the CI service reads this only once at startup and then
> should
> wait on events?
> 
> Anything basing on a CD ROM device should be able to handle ejects or
> inject at any time...
> 
> @Alexandre, did you test how good the Cloudinit clients handle this?
> 
> > This would be different if we used a network-based cloud-init
> > solution,
> > but that would just "shift" the required effort from the whole
> > state
> > keeping thomas mentioned below to actually getting this onto a
> > network
> > interface *per vm* and in a sane way.
> > 
> > But yes, I can honestly also say that if you're changing cloud-init
> > data
> > while the VM is currently reading it and it just crashes and you
> > have to
> > hit the reboot button... that's perfectly fine with me actually.
> > 
> 
> CI crashing means probably that that change is not applied, not that
> the
> VM is rendered unusable. So you can only win, as at max for applying
> changes
> you have to do the same as you had to do always without such a change
> anyway: reboot
>