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

[Oguz Bektas]

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.