Maybe, another way, instead writing [cloudnit:special] section, we could write this config section inside the drive image directly when we generate it (to avoid to reparse format generate config)
so we could read the drive to display the diff in the gui (we already have an cloudinit dump api, don't seem to be slow) what do you think about this ? Le jeudi 01 avril 2021 à 12:22 +0200, aderum...@odiso.com a écrit : > Le jeudi 01 avril 2021 à 10:54 +0200, Thomas Lamprecht a écrit : > > > > actually, why isn't the pending section enough for this? > > > > If stuff can be hot plugged then we can do so and if only that > > changed we > > can just remove it from pending, as normally? > > Well, for example, if you change the vm name , how to you manage that > ? > do you want to keep it as pending until we regenerate cloudinit > drive? > > or more complex, if you change the mac address of the vm. (so > unplug/replug the nic) > for the nic, you don't want to keep it as pending, as technically, is > really plugged. > > or if you change the storage of the cloudinit drive, currently they a > no way to known if we need to regenerate it. > > The main problem is that pending section, is more for pending qemu > change, > not pending cloudinit config drive regeneration. > > For me, both are differents. > > > Currently,it's working well when vm is offline, because we don't have > any pending, and we regenerate the disk at vm startup. > > > (I'm really looking to use cloudinit for online config changes, like > for containers) > > > > > > > > > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
