-
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
updating label in KEP-3257 #4971
base: master
Are you sure you want to change the base?
updating label in KEP-3257 #4971
Conversation
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.
LGTM
@@ -290,7 +290,7 @@ kind: ClusterTrustBundle | |||
metadata: | |||
name: example.com:server-tls:foo | |||
labels: | |||
kubernetes.io/cluster-trust-bundle-version: live | |||
k8s.example/cluster-trust-bundle-version: live |
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.
nit: I'd suggest sticking with example.com as the label namespace, consistent with the signer name domain
k8s.example/cluster-trust-bundle-version: live | |
example.com/cluster-trust-bundle-version: live |
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.
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.
#4971 (comment) was a nit, but it makes sense to me.
(no need to check with docs folks on this - the logic about the change was to avoid implying there's a known label key)
Label keys aren't API, but we still like to note which ones are recognized and which aren't.
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.
Label keys aren't API, but we still like to note which ones are recognized and which aren't.
Is this for labels set by users? I thought those were part of the Kubernetes API.
Even if a label is only set by a Kubernetes component, it might still be part of the API (read by users). At the very least they need to be considered during upgrade/downgrade scenarios, just like "normal" APIs.
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.
You use the API to manage labels, but we don't apply API stability guarantees to what keys are set and what values they can have.
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.
In this case or in general?
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.
For all labels and annotations, we don't apply API stability guarantees to what keys are set and what values they can have.
/approve I'm happy with this change. Even better to fix up per #4971 (comment) |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Ritikaa96, sftim 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 |
kubernetes.io/cluster-trust-bundle-version
tok8s.example/cluster-trust-bundle-version
as per the discussion on Labelkubernetes.io/cluster-trust-bundle-version
not documented website#41481 (comment)