-
Notifications
You must be signed in to change notification settings - Fork 492
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
Removing scope fields from object references #882
Conversation
Our object references use kind instead of resource which requires implementations to have a predefined kind->resource mapping. That means there can never be ambiguity within an implementation as far as whether a reference is to a cluster-scoped or namespace-scoped resource. This also removes the ability for ParentRef to refer to cluster-scoped resources. Although we can add that in the future with a docs update, there do not appear to be any use cases for that today.
Adding a hold until we have consensus on this. /hold |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: howardjohn, robscott The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
Follow up: @hbagdi found the original discussion that resulted in the introduction of scope: kubernetes/enhancements#2366 (comment). Although we were concerned that the initial rationale may have been broader than ambiguity, it seems like that really was the primary concern. |
That comment does make clear that what we're doing for GatewayClass is not preferred, although personally, I'm okay with it in this case. |
/lgtm |
Discussed at community meeting yesterday as well, it seems like there's pretty broad consensus on this change. /hold cancel |
What type of PR is this?
/kind cleanup
/kind api-change
What this PR does / why we need it:
Our object references use kind instead of resource which requires implementations to have a predefined kind->resource mapping. That means there can never be ambiguity within an implementation as far as whether a reference is to a cluster-scoped or namespace-scoped resource.
This also removes the ability for ParentRef to refer to cluster-scoped resources. Although we can add that in the future with a docs update. There do not appear to be any use cases for that today.
Which issue(s) this PR fixes:
Fixes #838
Does this PR introduce a user-facing change?: