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

[Thomas Lamprecht]

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