Add patchMergeKey annotations to allow Kustomize overrides of list element fields

[johananl]

User Story

As a developer I would like to be able to override fields of list elements in CAPI types using Kustomize so that I can leverage Kustomize for keeping workload cluster templates DRY.

Detailed Description

Kustomize is used by CAPI providers to keep cluster templates DRY. Example: https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/4b535f6befba3b08dee7250d7dd83590757709ad/test/e2e/data/infrastructure-vsphere/kustomization/conformance/kustomization.yaml#L1

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  ...
spec:
  kubeadmConfigSpec:
    ...
    files:
    - content: |
        foo
      path: /tmp/foo
      permissions: "0644"

Assume I want to use Kustomize to override the permissions field of the files entry above (but keep the content and any other field intact). At the moment, patching the list element using Kustomize replaces the list element rather than patch it.

As far as I can tell, this is caused by the fact that the File type doesn't have a patchMergeKey annotation (which should probably be on the path field):

cluster-api/bootstrap/kubeadm/api/v1beta1/kubeadmconfig_types.go

Line 211 in 8059056

type File struct {

Relevant info: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#merge-individual-elements-of-a-list-of-complex-elements

I'm wondering if adding a patchMergeKey annotation for all the CAPI types makes sense. Looking at the repo, it seems there is only one annotated type:

cluster-api/api/v1alpha3/common_types.go

Line 189 in 58905fb

// +patchMergeKey=uid

Anything else you would like to add:

None

/kind feature

[sbueringer]

Sounds good to me. I ran into this issue before and had to switch to JSON patching (IIRC).

P.S. Not 100% sure, but I think it can be also useful for kubectl apply when a list is updated.

[fabriziopandini]

/kind api-change

I'm generally +1, just wondering if:

• can we generalize and check the entire API for similar cases?
• does this qualify as a breaking change?

/milestone v1.2
According to the answer to the above questions we can eventually re-consider

[sbueringer]

does this qualify as a breaking change?

I think it depends on how/if it changes things like kubectl apply behavior
(and if it changes the behavior, if it only fixes error cases or if it leads to different results)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[johananl]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[johananl]

/remove-lifecycle stale

[fabriziopandini]

/lifecycle frozen

[fabriziopandini]

/triage accepted

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[fabriziopandini]

/priority important-longterm

[fabriziopandini]

This should be part of the next API iteration
/triage accepted