On 2/6/20 5:13 PM, Oguz Bektas wrote: >> Further, while this resolves the issue of a broken config in general the >> underlying "when are config property values equal" is not solved. I can >> still trigger a fake pending change. For example, assume the following >> config property present and applied already: >> >> mp0: tom-nasi:110/vm-110-disk-0.raw,mp=/foo,backup=1,size=102M >> >> Now a API or CLI client (in this case simulated through pct) sets it to the >> same semantic value, but switched order of property strings: >> # pct set 110 --mp0 mp=/foo,tom-nasi:110/vm-110-disk-0.raw,backup=1,size=102M >> >> I get a pending change, but there'd be none. Same issue if I do not switch >> order of properties in the string but one time a default_key is present >> verbose "enabled=1", and one time in it's short form "1". > indeed. but i think this isn't that tragic since it doesn't break any > functionality (i think?).
No, it isn't tragic at all, but it is confusing and IMO not nice API behavior. > >> The correct solution would be parsing the properties and doing a >> deterministic >> (deep) compare. >> A heuristic could be ensuring that at least our webinterface and backend >> always >> print property strings the same way (i.e., sorted) - that would be possible >> cheaper but not solve that effect for all clients using the API. >> > but still if you want i can take a look at implementing that soon. > Yes, but I'd treat it rather lower priority. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
