You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before the switch to kyaml, there was an attempt to warn (and fail, with no option
to ignore) if two or more strategic merge patches in one kustomization file did
not commute, i.e. you'd get a different result if you applied them in a different order.
E.g. two patches changing the same field (the last patch applied would win).
To accurately warn, one would have to apply all patches in all possible orders
up the kustomization stack (n factorial) and confirm that the results were the
same (that patches were commutable over the domain).
That could be a lot of computation to enforce the commutability, without the
ability to shut it off. In some cases, one might want a final patch
to trump earlier patches .
The actual check never did this, opting for a shorter heuristic the merged only
the patches in one kustomization file into one SMP, looking for conflicts in that
isolated window. There does not appear to be a specification one could use
to extend conflict detection to CRDs, and SMP won't be supported for
CRDs (kubernetes/kubernetes#58414).
Since the conversion to kyaml, this code is no longer executed, but is still in place.
Even before the switch, it was only used in the context of the patchesStrategicMerge
field, and never used in the patches field (which also performs SMP, if the patch fails
to parse as a JSON patch).
Conflict detection was never attempted in JSON patching.
So - drop the SMP conflict detector completely, there's no spec for to extend it
to CRDs. Hunt for ConflatePatches and Conflict.
The text was updated successfully, but these errors were encountered:
Before the switch to kyaml, there was an attempt to warn (and fail, with no option
to ignore) if two or more strategic merge patches in one kustomization file did
not commute, i.e. you'd get a different result if you applied them in a different order.
E.g. two patches changing the same field (the last patch applied would win).
To accurately warn, one would have to apply all patches in all possible orders
up the kustomization stack (n factorial) and confirm that the results were the
same (that patches were commutable over the domain).
That could be a lot of computation to enforce the commutability, without the
ability to shut it off. In some cases, one might want a final patch
to trump earlier patches .
The actual check never did this, opting for a shorter heuristic the merged only
the patches in one kustomization file into one SMP, looking for conflicts in that
isolated window. There does not appear to be a specification one could use
to extend conflict detection to CRDs, and SMP won't be supported for
CRDs (kubernetes/kubernetes#58414).
Since the conversion to kyaml, this code is no longer executed, but is still in place.
Even before the switch, it was only used in the context of the
patchesStrategicMerge
field, and never used in the
patches
field (which also performs SMP, if the patch failsto parse as a JSON patch).
Conflict detection was never attempted in JSON patching.
So - drop the SMP conflict detector completely, there's no spec for to extend it
to CRDs. Hunt for
ConflatePatches
andConflict
.The text was updated successfully, but these errors were encountered: