-
Task
-
Resolution: Unresolved
-
Undefined
-
None
-
None
This task is to design ACM-1683. Essentially, we want a way to give the user a "merge" experience similar to `kubectl apply` rather than just our own custom logic of `MustHave` and `MustOnlyHave`. This benefits from additional metadata in native types and CRDs that describe how to merge lists of objects. We currently only key on things like the `name` field of an object in a list.
As part of this design, research both strategic merge (client side) and server side apply (with field manager ownership) and choose which approach is best.
Open Questions:
- Is strategic merge good enough? Can we do this merging client side with the OpenAPI data?
- It seems Argo CD uses it this way https://github.com/argoproj/gitops-engine/blob/72bcdda3f0a5b80432d9f72e5b30827a530ac349/pkg/diff/diff.go#L956
- If a server side apply is used (dry run for inform case), should the config-policy-controller always take ownership of fields (i.e. ignore conflicts from managedFields)? If not, should there be an option to override? This could help detect the conflicting controller cases.