✨ New kubebuilder:schemaModifier CRD marker#1140
✨ New kubebuilder:schemaModifier CRD marker#1140yaroslavborbat wants to merge 2 commits intokubernetes-sigs:mainfrom
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
Welcome @yaroslavborbat! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @yaroslavborbat. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: yaroslavborbat The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/L
yaroslavborbat
force-pushed
the
add-marker-schemaModifier
branch
from
71a1237 to
d0371a8
Compare
chrischdi
left a comment
chrischdi
left a comment
There was a problem hiding this comment.
This should have unit-test coverage.
I'd like to understand the use-case some more: Can't this be done by just not setting markers at some fields?
I guess this does not work e.g. for description, but I don't get it for other fields.
|
Where there are lists, for example an enum, would you need to specify the entire enum with this marker, and how would that look? What separators are used? Does this encourage the use of/give folks the ability to create schemas that aren't valid? I wonder if we want to encourage patching schemas in ways that could be foot guns? WDYT? |
|
Hi @chrischdi! I'll add test coverage for this soon. This approach works for description and should also work for other fields. CRD markers are processed last, when the full schema has already been generated, so we can traverse it recursively and modify fields as needed. One key use case is when defining a CRD that includes imported types. Since we cannot modify or extend annotations on those types directly, this marker allows us to adjust their schema properties where necessary. |
|
Hi @JoelSpeed! Here’s an example of how I replaced the required list and the description: // +kubebuilder:schemaModifier:pathPattern=/spec/testObject,required={"field1", "field2", "field3", "field4"},description="new my description"Regarding schema validity, this marker does allow users to generate an invalid schema if used incorrectly, so it should be used with caution. At the same time, it provides additional flexibility in CRD generation. Personally, I found such a marker useful, which is why I created this PR 🙃. |
k8s-ci-robot
added
the
needs-rebase
k8s-ci-robot
added
the
do-not-merge/work-in-progress
Signed-off-by: Yaroslav Borbat <yaroslav.752@gmail.com>
yaroslavborbat
force-pushed
the
add-marker-schemaModifier
branch
from
d0371a8 to
6e975fe
Compare
k8s-ci-robot
added
size/XL
yaroslavborbat
force-pushed
the
add-marker-schemaModifier
branch
from
ad12827 to
e92864e
Compare
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
Hi @chrischdi @JoelSpeed, sorry for the long silence on this PR. I've added unit tests for the marker functionality. Additional test coverage can be added if specific scenarios require it. The main use case for kubebuilder:schemaModifier is to allow modifying schema properties in generated CRDs without changing the underlying Go types. This is particularly useful when working with external or generated types that cannot be modified directly. |
k8s-ci-robot
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions 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. |
|
|
||
| junit-report.xml | ||
| /artifacts | ||
| tmp No newline at end of file |
There was a problem hiding this comment.
Nit, missing the new line char at the end
| // The PathPattern field defines the rule for selecting target fields within the CRD structure. | ||
| // This rule is specified as a path in a JSONPath-like format and supports special wildcard characters: | ||
| // - `*`: matches any single field name (e.g., `/spec/*/field`). | ||
| // - `**`: matches fields at any depth, across multiple levels of nesting (e.g., `/spec/**/field`). |
There was a problem hiding this comment.
What is the use case for patterns? This seems like it could have unintended consequences/people may not realise quite how much impact it might have
| // - `**`: matches fields at any depth, across multiple levels of nesting (e.g., `/spec/**/field`). | ||
| // | ||
| // Example: | ||
| // +kubebuilder:schemaModifier:pathPattern=/spec/exampleField/*,description="" |
There was a problem hiding this comment.
What would an example of this with something that is not just a simple string look like? E.g. required?
| // In this example, all fields matching the path `/spec/exampleField/*` will have the empty description applied. | ||
| // | ||
| // Any specified values (e.g., Description, Format, Maximum, etc.) will be applied to all schemas matching the given path. | ||
| type SchemaModifier struct { |
There was a problem hiding this comment.
Is the list of fields comprehensive, and, if so, how can we ensure in the future, if additional fields are needed, that we do not forget to add them?
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closed this PR. DetailsIn response to this:
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. |
5 participants
Overview
Closes #441
This pull request introduces a new marker
kubebuilder:schemaModifier, which allows modifying specific fields inJSONSchemaPropsfor CustomResourceDefinitions (CRDs). This marker supports flexible rules for targeting specific paths in the CRD schema and allows setting multiple properties at once.Details
New Marker:
kubebuilder:schemaModifierThe
schemaModifiermarker operates on CRD schemas and enables users to apply modifications to specific fields. The targeting of fields is achieved using thePathPatternattribute, which defines a path-matching rule using a JSONPath-like syntax:*: Matches any single field name (e.g.,/spec/*/field).**: Matches fields across multiple levels of nesting (e.g.,/spec/**/field).This marker can update multiple properties in
JSONSchemaProps, such asDescription,Format,Maximum,Nullable, and others.Example:
// +kubebuilder:schemaModifier:pathPattern=/spec/exampleObject/*,description=""The above example applies the empty description to all fields matching /spec/exampleObject/*.
How This Was Tested
marker covered with unit tests
ginkgo --focus="SchemaModifierMarker" ./pkg/crd/markers/...