Remove setters code from cmd/config and kyaml

[phanimarupaka]

Setters functionality is provided as a KRM function. We should remove code related to setters in cmd/config and kyaml.

[k8s-ci-robot]

@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 triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[phanimarupaka]

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

[natasha41575]

I have cycles to pick this up but also would like clarity on how to deprecate the commands kustomize cfg create-setter and kustomize cfg set and if and how we need to communicate this to users. Since they are alpha, can we just remove them?

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?

[KnVerey]

Since they are alpha, can we just remove them?

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.

it seems like we should only remove them when we are ready to do a major release. @KnVerey could you clarify the timeline?

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.

[natasha41575]

The commands will be marked deprecated in the next release. We can remove the code as part of the kustomize CLI v5 release.

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[KnVerey]

/remove-lifecycle stale

all deprecations are out in the latest release

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[KnVerey]

/remove-lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[KnVerey]

/remove-lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[natasha41575]

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.

[khrisrichardson]

I see a couple examples outside of kpt:

fluxcd/image-automation-controller
rancher/fleet

[irvifa]

/assign

[irvifa]

@natasha41575 I've tried to search of the setters and setters2 usage and most of them related to fork of kpt, however, these:
fluxcd/image-automation-controller with kyml
rancher/fleet with kyaml

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.

[natasha41575]

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!

[natasha41575]

Also a note, the issue itself should stay in "in progress" - "Needs LGTM" is just for PRs.