[pve-devel] applied: [PATCH container] apply_pending: call cleanup_pending between change/delete loops

[Thomas Lamprecht]

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.