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). _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
