-
Notifications
You must be signed in to change notification settings - Fork 422
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
⚠️ Only prevent validation of top-level ObjectMeta field #395
Conversation
/assign @DirectXMan12 |
cca9bfe
to
fa0f5d9
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: arjunrn The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Arjun Naik <arjun.rn@gmail.com>
fa0f5d9
to
774f758
Compare
FWIW, this patch worked to fix our use case in prometheus-operator (prometheus-operator/prometheus-operator#3041) |
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. |
Stale issues rot after 30d 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. |
/remove-lifecycle rotten |
Title edit: this is a breaking change |
@arjunrn: PR needs rebase. 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. |
it almost sounds like we want |
I think this approach is fairly reasonable, but it is a breaking change. We should have a generator option to turn this on or off, I think. Please add that, and then this is good to go. |
(also, I realize this is super old at this point, so if the original submitter is no longer available and someone wants to take this over, please do) |
I still think it is not a good idea to have full ObjectMeta in an embedded object. The technical work around is have some special EmbeddedObjectMeta with a restricted set of fields. I think that's the route that some operators went by now. |
What do we do about |
Sins of the past. Do we have any restriction on PodTemplateSpec in contrast to object-top-level meta data? We should have gone the same way there, i.e. EmbeddedObjectMeta. |
For operators that are already deployed re-organizing the CRD to add embeddedObjectMeta may not be feasible for an upgrade. If we could keep at least the name/namespace (typically these get referenced by other objects) of the ObjectMeta around post conversion, that would help. #448 Thanks |
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. |
Stale issues rot after 30d 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. |
/remove-lifecycle rotten |
Closing in favor of #539 |
This addresses #385. Currently the validation for
ObjectMeta
is not generated even if it is used somewhere in the schema other than at the top-level. To fix this I mostly reverted the changes from #266 and then after the schema has been generated patched the top-levelmetadata
to have no validation. The resulting schema forObjectMeta
is still big as @sttts mentions in the issue but I don't see how we can drop only the read-only fields. We can have a hand-written schema with only the required fields but this would need more effort in the long term keeping it in sync with upstream. I'm open to suggestions on how this can be improved.