[pve-devel] [PATCH container 1/9] add pending section to lxc config parser/writer

[Fabian Grünbichler]

On September 11, 2019 2:02 pm, Thomas Lamprecht wrote:
> On 11.09.19 09:39, Fabian Grünbichler wrote:
>> NAK, this breaks existing configs with a snapshot called pending (which 
>> is an allowed snapshot name, and not such an uncommon word that we can 
>> confidently say that noone would be affected). we could do _PENDING_ or 
> 
> naming it pending for VMs was possible and broke things in obvious ways,
> nevertheless we never had a single report about it, AFAICT, even after
> pending being released ~4.5 years ago. So while yes, the chance is there
> I'd guess that's highly unlikely - not that that really helps us.
> 
>> __PENDING__ (similar to what we do with __base__ and __replicate__ and 
>> __migration__ storage snapshots).
> 
> confuses things more, IMO, the other two are special snapshots, this is
> completely something different, so mixing those two into having a similar
> syntax may make people think that "__PENDING__" is a pending snapshot.
> 
> IMO, the snapshots should have been prefixed with a marker from the
> beginning, but as the time machine isn't there yet and retro actively
> re-writing snapshot sections as "[snap:<name>]" or the like isn't a to
> easy task, I'd maybe rather add a prefix for non-snapshot sections with
> a snapshot incompatible syntax. [_special:PENDING] or the like.
> 
> Another possible way could be to really to the 
> [snap:<name>] for snapshots, rewriting old ones once the config is written
> out for other changes anyway, and for names where we are not sure like
> "pending" check if's there's a "snaptime" property in the section?
> As else it cannot be a valid snapshot made through the API.

we had a bit of offline discussion yesterday about this, IMHO 
namespacing the sections would be the best way to go forward.

either special: or pve: for stuff like 'pending', snap: or snapshot: for 
snapshots. since we don't allow ':' in section names currently, this 
could be done fairly backwards-compatible (plain 'pending' would be 
handled differently for qemu-server and pve-container).. vzdump filters 
both pending and snapshots from the stored config, replication is 
frequent enough, so we don't really have to worry about long-term 
compat, just for one release cycle.. the hash representation can stay 
liek it is, so no big code changes needed either, besides the par 
ser/writer and qemu-server's vzdump (which has its own filtering config 
reader).