Support RFC6902 json patches for manifests

[simplysoft]

User Story

As a user I would like to patch the manifest using RFC6902 in addition to json merge patch support introduced with #280 so that I can e.g. easily add command arguments to conainers

Detailed Description

json merge patch (RFC 7396) has the limitation that is not possible to extend lists (without having to duplicate existing elements in the patch itself) or do some more advanced patches.

The underlying evanphx/json-patch library used would already support this, but operator currently does not.
It would be great to extend support, ideally in similar way than kustomize supports different patch types, e.g.

- patch: |
    - op: add
      path: /spec/template/spec/containers/0/args/-
      value: --additional-sync-machine-labels=topology.kubernetes.io/.*
  target:
    kind: Deployment

/kind feature

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[hjoshi123]

@simplysoft I am interested in working on this since I ran into this during my capi operator approach. Do you think I can take this up?

[nalum]

@hjoshi123 did you get the chance to look at this? If not I'm happy to do so, I've gotten a start exploring it already.

Who would be good to talk to about making changes?

[hjoshi123]

@nalum I do have an implementation and I can raise a PR this weekend. We can discuss on it if it looks good or something else needs to be done.

[hjoshi123]

/assign

[hjoshi123]

@nalum wanted to confirm my approach with you.. I was thinking to keep the existing resourceManifest patches and do a comparison.. if the resulting patch is an object then use the merge patch if its an array use RFC6902. This way we dont have to change the existing behavior from the user perspective. How does that sound?

[nalum]

@hjoshi123 the approach i was going to take was to add spec.patches as a new field which is a list of the structure outlined and mark the existing spec.manifestPatches as deprecated, meaning we don't need a new api version and existing resources continue to work.

I wanted to ask the maintainers on this approach and if importing packages that already do this work from the Flux controllers was acceptable. The following packages could be used:

• https://github.com/fluxcd/pkg/tree/main/runtime%2Fpatch
• https://github.com/fluxcd/pkg/tree/main/apis%2Fkustomize

If using these is not acceptable then I was planning to implement similar packages.