-
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 setters code from cmd/config and kyaml #4045
Comments
@phanimarupaka: This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the The 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 Let me know if you have cycles to pick this up. @KnVerey Since cmd/config commands are alpha in kustomize, please let us know the best way to deprecate them and user communication. I am not sure if there are users for those commands apart from kpt. |
I have cycles to pick this up but also would like clarity on how to deprecate the commands Related: #3953 Discussion there agrees with removing these commands, but is under the project Kustomize CLI v5, so it seems like we should only remove them when we are ready to do a major release. @KnVerey could you clarify the timeline? |
Great question. Any idea if there is precedent to follow here? Perhaps you're right and we can just remove them without warning in 5.0... or maybe even before then? Re: communication, a release note pointing to docs for the KRM function should suffice, I think.
The idea is to group together all the breaking changes we've been wanting to make into a single release, to minimize the number of times users have to engage with an update. Partly timeline depends on how we want to handle the Kustomization v1 project. Historically, it seems like breaking changes to Kustomization were made by incrementing the CLI major version instead of the Kustomization version. Since we're necessarily changing the Kustomization version with that project, I think the "right way" (higher effort) would be to have a CLI version that supports both beta and v1, and then eventually remove beta support in another major CLI version. We'll need to check with @monopole on that. The other thing CLI 5.0 timeline depends on is deprecation of flags--because those WILL need a proper deprecation cycle, given that the CLI is already GA. |
The commands will be marked deprecated in the next release. We can remove the code as part of the kustomize CLI v5 release. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale all deprecations are out in the latest release |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The setters code lives here I think: https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml/setters2 and https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml/fix/fixsetters. Can someone investigate if we are still using these package anywhere? If not, we can probably just take it out entirely. I don't think we need to continue to support setters-related code. The only other project that I know has a similar concept of setters is kpt and kpt functions, so it would be helpful if whoever investigates this can also check if they are depending on any of the setters code in kyaml as well. |
I see a couple examples outside of kpt: |
/assign |
@natasha41575 I've tried to search of the setters and setters2 usage and most of them related to fork of kpt, however, these: Are still using them, They pinned these two into a specific kyaml version. If we decide to go for this removal then we can make a release note that this is actually removed on the next version since we already marked this as deprecated before. |
SGTM! |
Also a note, the issue itself should stay in "in progress" - "Needs LGTM" is just for PRs. |
Setters functionality is provided as a KRM function. We should remove code related to setters in cmd/config and kyaml.
The text was updated successfully, but these errors were encountered: