On Thu, Feb 06, 2020 at 05:15:18PM +0100, Thomas Lamprecht wrote: > 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.
agreed. > > > > >> 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. alright, i'll take a look next week. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
