updating label in KEP-3257

[Ritikaa96]

• One-line PR description: Updating the label kubernetes.io/cluster-trust-bundle-version to k8s.example/cluster-trust-bundle-version as per the discussion on Label kubernetes.io/cluster-trust-bundle-version not documented website#41481 (comment)

• Issue link: ClusterTrustBundles (previously Trust Anchor Sets) #3257

[sftim]

LGTM

[liggitt]

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

[Ritikaa96]

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

[sftim]

#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.

[pohly]

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.

[sftim]

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.

[pohly]

In this case or in general?

[sftim]

For all labels and annotations, we don't apply API stability guarantees to what keys are set and what values they can have.

[Ritikaa96]

#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.

Thanks @sftim for clarification. i'll update the label then.

[sftim]

/approve

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

[k8s-ci-robot]

[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:

• keps/sig-auth/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Ritikaa96]

Hi @sftim, @pohly and @liggitt , i have changed the label as per suggestion. PTAL!
Thanks a lot for the review.

[liggitt]

/lgtm