Utilize x-kubernetes-list-type and x-kubernetes-list-map-keys annotations

[tsekine354]

Eschewed features

• [x] This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

kustomize seems to support x-kubernetes-patch-strategy and x-kubernetes-patch-merge-key annotations for strategic merge patch. It's fine, but those annotations are not supported in CRD as mentioned in https://github.com/kubernetes/kubernetes/issues/118241.

Instead of them, CRDs have x-kubernetes-list-type and x-kubernetes-list-map-keys attributes as explained in Extend the Kubernetes API with CustomResourceDefinitions (though, it should have a typo in the attribute name. See https://github.com/kubernetes/apiextensions-apiserver/blob/0350e46ec6f2c9fdb42bf74aa2da55fa8164150e/pkg/apis/apiextensions/types_jsonschema.go#L110 for the correct name).

If kustomize supports CRD for strategic merge patch, kustomize should utilize x-kubernetes-list-type and x-kubernetes-list-map-keys instead of x-kubernetes-patch-strategy and x-kubernetes-patch-merge-key (they must be kept supported for builtin k8s APIs).

BTW, if "strategic merge patch" should be equivalent of kubectl patch, kustomize should raise an error, instead of silently treat all lists as replace-only lists.

For instance, kubectl patch --type=strategic doesn't work for custom resource, e.g.

$ kubectl patch --dry-run=client ... --patch some.patch.yaml 
error: strategic merge patch is not supported for example.com/v1, Kind=Example locally, try --type merge

That's frustrating, but that's reasonable behavior.

Why is this needed?

We have some CRDs where some arrays are annotated by x-kubernetes-list-type and x-kubernetes-list-map-keys (or // +listType=map annotation in go source, consumed by contoller-gen tool), as those are list of objects, keyed by "name" field.

The contents of the list are regularly updated, potentially by non engineers or by automation tools. We could edit a gigantic resource file, but we really want to split out those contents to other files as patch, so that people can edit those patch files easily, or it's more easy to just generate new files by some automation tool instead of editing the gigantic resource file.

Can you accomplish the motivating task without this feature, and if so, how?

We could convert our CRD to OpenAPI format, by kustomize openapi fetch, then edit it by following https://github.com/kubernetes-sigs/kustomize/blob/master/examples/customOpenAPIschema.md to inject x-kubernetes-patch-strategy and x-kubernetes-patch-merge-key, maybe by some scripting.

But it's little cumbersome and I feel that I'm doing something wrong.

What other solutions have you considered?

We may stop using kustomize and use jsonnet instead.

We have ongoing discussions internally, which is better for us.

Anything else we should know?

Current CRD support of kustomize looks half-way. If kustomize support custom resource for strategic merge, please respect the spec of CRDs, instead of asking users to do some additional work on top CRDs.

Feature ownership

• [ ] I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

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.

[tsekine354]

I've researched little bit more. I've noticed that, x-kubernetes-list-map-keys was added in #3159.

I think, bug report #3111 was inaccurate, so it was implemented improperly.

K8S API had x-kubernetes-patch-strategy and x-kubernetes-patch-merge-key combination for strategic merge patch (or, kubectl patch). After that, x-kubernetes-list-type and x-kubernetes-list-map-keys combination was added to the Open API spec for CRD (+ Server-Side Apply).

Those are always paired. So, PatchStrategyAndKeyList in ./kyaml/openapi/openapi.go is supposed to modified as something like

1. Inspect x-kubernetes-list-type in the schema.
2. If x-kubernetes-list-type exists and its value is map, parse x-kubernetes-list-map-keys as list of keys and return it.
3. Inspect x-kubernetes-patch-strategy in the schema
4. If x-kubernetes-patch-strategy exists and its value is merge, parse x-kubernetes-patch-merge-key as the key and return it.

Those are always paired. Don't mix them.

[tsekine354]

Note that, this is not a feature request anymore. This is a bug.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[dpozinen]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[MaximizeRr]

/remove-lifecycle stale