-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Remove duplicate label behavior: commonLabels vs labels.includeSelectors #5436
Comments
I agree that we should remove the duplicate behavior, but we need to be careful and adhere to the deprecation policy. Between the two options that you listed, I think it probably makes more sense to deprecate I think this has been discussed in the past, and rather unfortunately we cannot just remove a field from the kustomization definition as it is defined in the current v1beta1 version. We would have to include the removal as part of the definition of kustomization v1; then we would have to deprecate kustomization v1beta1 entirely. During the deprecation cycle (which I believe lasts at least 2 releases), we would have to support both kustomization v1 and kustomization v1beta1 before the eventual removal of kustomization v1beta1. If you don't mind, I'd like to discuss this in the monthly kustomize bug scrub (there's one next week) so that we can make sure everyone is on the same page before we triage it. |
/kind deprecation |
/remove-kind feature |
/triage accepted |
For now, we can add a deprecation warning to For long-term removal, we will have to move the kustomization v1 project forward, which has some nontrivial design & feature work. /label good-first-issue |
@natasha41575: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed In response to this:
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. |
@natasha41575: The label(s) In response to this:
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. |
As noted in #5527 (comment), while |
Eschewed features
What would you like to have added?
The
commonLabels
andlabels
fields withincludeSelectors
enabled produce the same output. It is preferable to have one method to add labels that are propagated to selectors and templates.The sample kustomization files below would produce the same output.
Why is this needed?
We should remove duplicate behavior where possible to potentially simplify our kustomization API.
Can you accomplish the motivating task without this feature, and if so, how?
We can produce the same result with either
commonLabels
andlabels
fields.What other solutions have you considered?
We can remove duplicate behavior with multiple approaches.
Option 1: Deprecate
commonLabels
commonLabels
field and exclusively use thelabels
field.annotations
field with anincludeTemplates
option. This would mirror thelabels
field spec.Option 2: Deprecate
labels
labels
field and addincludeSelectors
andincludeTemplates
options to thecommonLabels
field.includeTemplates
option to thecommonAnnotations
field.Anything else we should know?
This was identified when documenting labels and annotations behavior here: #5383
Feature ownership
The text was updated successfully, but these errors were encountered: