Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Ritikaa96
Copy link
Contributor

@Ritikaa96 Ritikaa96 commented Nov 21, 2024

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Nov 21, 2024
@k8s-ci-robot k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Nov 21, 2024
Copy link
Contributor

@sftim sftim left a 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
Copy link
Member

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

Suggested change
k8s.example/cluster-trust-bundle-version: live
example.com/cluster-trust-bundle-version: live

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it is just an example, we can make this change, but as it is noticed as an k8s label, should we add the example.com instead of k8s.example? @sftim , WDYT?
Thanks for the review @liggitt

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

@sftim
Copy link
Contributor

sftim commented Nov 25, 2024

/approve

I'm happy with this change. Even better to fix up per #4971 (comment)

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Ritikaa96, sftim
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Kubernetes Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants