Skip to content

Cannot run patchesStrategicMerge on CRDs schema under Versions array #113223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
gaelgatelement opened this issue Oct 20, 2022 · 12 comments
Closed

Cannot run patchesStrategicMerge on CRDs schema under Versions array #113223

gaelgatelement opened this issue Oct 20, 2022 · 12 comments
Labels
kind/support Categorizes issue or PR as a support question. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. triage/accepted Indicates an issue or PR is ready to be actively worked on. wg/api-expression Categorizes an issue or PR as relevant to WG API Expression.

Comments

@gaelgatelement
Copy link

gaelgatelement commented Oct 20, 2022 •
edited
Loading

What happened?

When trying to use patchesStrategicMerge on CRD schema under spec/versions array, it fails and replace the whole array because it is missing a mergeKey and patchStrategy on Versions.

patchesStrategicMerge used to work with spec.version and spec.validation fields but those are now deprecated.

What did you expect to happen?

patchesStrategicMerge should be usable with new versions array.

How can we reproduce it (as minimally and precisely as possible)?

base.yaml :

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: foo.bug.local
spec:
  group: bug.local
  names:
    kind: Foo
    listKind: FooList
    plural: foos
    singular: foo
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        description: Foo is the Schema for the foos API
        properties:
          apiVersion:
            description: 'APIVersion defines the versioned schema of this representation
              of an object. Servers should convert recognized schemas to the latest
              internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
            type: string
          kind:
            description: 'Kind is a string value representing the REST resource this
              object represents. Servers may infer this from the endpoint the client
              submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
            type: string
          metadata:
            type: object
          spec:
            description: Spec defines the desired state of Foo
            type: object
            properties:
              bar:
                description: This should be present in the result
                type: object
              k8s:
                description: This field will be replaced by kustomize

kustomization.yaml :

resources:
- ./base.yaml

patchesStrategicMerge:
- |-
  apiVersion: apiextensions.k8s.io/v1
  kind: CustomResourceDefinition
  metadata:
    name: foo.bug.local
  spec:
    versions:
    - name: v1alpha1
      schema:
        openAPIV3Schema:
          properties:
            spec:
                k8s:
                  description: This should be present in the result
                  type: string

bar is missing from result : kustomize build bug/

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: foo.bug.local
spec:
  group: bug.local
  names:
    kind: Foo
    listKind: FooList
    plural: foos
    singular: foo
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        properties:
          spec:
            k8s:
              description: This should be present in the result
              type: string

Anything else we need to know?

This might be a breaking change, if people relies on patchesStrategicMerge to replace their CRDs versions content instead of adding/merging.

Kubernetes version

All versions supporting apiextensions.k8s.io/v1.

Cloud provider

--

OS version

No response

Install tools

No response

Container runtime (CRI) and version (if applicable)

No response

Related plugins (CNI, CSI, ...) and versions (if applicable)

No response
@gaelgatelement gaelgatelement added the kind/bug Categorizes issue or PR as related to a bug. label Oct 20, 2022
@k8s-ci-robot k8s-ci-robot added needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Oct 20, 2022
@gaelgatelement gaelgatelement mentioned this issue Oct 20, 2022
Closed
@gaelgatelement
Copy link
Author

gaelgatelement commented Oct 20, 2022 •
edited
Loading

/sig api-machinery

@k8s-ci-robot k8s-ci-robot added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Oct 20, 2022
@k8s-ci-robot
Copy link
Contributor

@gaelgatelement: The label(s) wg/api-machinery, committee/api-machinery cannot be applied, because the repository doesn't have them.

In response to this:

/sig api-machinery

/wg api-machinery
/committee api-machinery

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/test-infra repository.

@k8s-ci-robot k8s-ci-robot removed the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Oct 20, 2022
@gaelgatelement
Copy link
Author

/wg api-expression

@k8s-ci-robot k8s-ci-robot added the wg/api-expression Categorizes an issue or PR as relevant to WG API Expression. label Oct 20, 2022
@gaelgatelement
Copy link
Author

Let me know, if this issue is sensible enough, if I should go down writing a KEP about this API change.

@liggitt
Copy link
Member

liggitt commented Oct 24, 2022

I don't think it's a breaking change, since it did not change behavior for the v1beta1 endpoint. I would expect a single actor to define the versions for the CRD, since they also have to define the conversion between them. Independent ownership of different versions or of parts of the schema don't seem like a good thing to encourage.

@liggitt liggitt added kind/support Categorizes issue or PR as a support question. and removed kind/bug Categorizes issue or PR as related to a bug. labels Oct 24, 2022
@gaelgatelement
Copy link
Author

I don't think it's a breaking change, since it did not change behavior for the v1beta1 endpoint. I would expect a single actor to define the versions for the CRD, since they also have to define the conversion between them. Independent ownership of different versions or of parts of the schema don't seem like a good thing to encourage.

I understand your reluctance to this change. It's indeed a good point that partial ownership would become possible.

We are actually using this schema change locally in our repository to be able to build complex schemas in multiple kustomize steps before pushing it to the kubernetes API. I think this is a valid usecase, but I see that there would have unwanted side-effects if we pushed it to the main kubernetes schema aswell.

I feel like this possibility will have to stay local to our buildchain ?

@liggitt
Copy link
Member

liggitt commented Oct 24, 2022

If you're applying patches locally to construct a schema that is written to the server by a single actor, I'd suggest using a different patch type than strategic merge patch. You can get very fine-grained control of where and how the patch is applied with the json-patch type (https://kubectl.docs.kubernetes.io/references/kustomize/builtins/#_patchesjson6902_)

@gaelgatelement
Copy link
Author

Yes, we have been using this as well, but here we are trying to include metadata in every field of our CRD.

To be more precise, we are trying to add openapi specifications extensions which are not supported by k8s yet. So we build 2 distincts schema file : first the CRD which will be injected into k8s, and then we attach some x-ui-type field everywhere in the tree using a strategic merge patch.

Using the Json patch, it would be very verbose to do so, while with the strategic merge patch the patch is readable and easy to manage.

@alexzielenski
Copy link
Member

/triage accepted

thanks jordan

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 15, 2022
@k8s-triage-robot
Copy link

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

@k8s-ci-robot k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. and removed triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Jan 19, 2024
@seans3
Copy link
Contributor

seans3 commented Feb 9, 2024

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Feb 9, 2024
@liggitt
Copy link
Member

liggitt commented Feb 9, 2024

/close

as working as intended

@liggitt liggitt closed this as not planned Won't fix, can't repro, duplicate, stale Feb 9, 2024
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
6ae75ac 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kuberneten object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#113223
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
f29e521 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kuberneten object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#113223
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
df1e6ff 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kuberneten object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
- kubernetes/kubernetes#113223
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
0d41fd3 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kubernetes object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
- kubernetes/kubernetes#113223
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/support Categorizes issue or PR as a support question. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. triage/accepted Indicates an issue or PR is ready to be actively worked on. wg/api-expression Categorizes an issue or PR as relevant to WG API Expression.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add merge key crd versions gaelgatelement/kubernetes
6 participants
@alexzielenski @liggitt @seans3 @k8s-ci-robot @k8s-triage-robot @gaelgatelement
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy