-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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.
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
Structured-merge-diff support #1081
Comments
Note that uses who are currently referring to code which uses these tags already, such as in pod templates within custom controllers, will see a change to their generated CRD when they upgrade their KubeBuilder version. Need to determine how to explain this to users. To do that, need to understand what will happen. |
Does the actual desierialization of CRD validation schemas support it yet? IIRC, that was the blocker. |
otherwise, yeah, we should open an issue in controller-tools for this |
I think it's been done in 1.16. Let me double-check that. |
Yes. This is done in 1.16 so this is no longer blocked |
cool, we should cross-file on CT then |
I am wondering how we can do a better job of educating the users about using these markers when they use a list in their API definition. One idea that comes to mind is some sort of |
(btw, I'm working on the implementation right now) Yes, I'm trying to look at the documentation holistically right now, there are lots of gaps in that area. Making it obvious to CRD authors that this is a thing would help by calling out this specifically in CRD docs (I'm also working on this). A fairly obvious way to make a linter is to find specific patterns (@pwittrock already used that principle) like search for lists that have a field |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This was absolutely fixed by kubernetes-sigs/controller-tools#347 |
I want KubeBuilder to support these comment tags:
These are supported by https://github.com/kubernetes/kube-openapi (see here ) and I believe they are supported by Server-side apply for CRDs in 1.16.
KubeBuilder should be able to emit these properties when generating CRDs.
Related issues:
Requires 1.16
/kind feature
The text was updated successfully, but these errors were encountered: