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
graduate LegacyServiceAccountTokenNoAutoGeneration to ga #112838
Conversation
/triage accepted |
/cc @liggitt |
it looks like some providers still disable this - https://grep.app/search?q=LegacyServiceAccountTokenNoAutoGeneration%3Dfalse before removing autogeneration support, it would be good to understand why, and what their timeframe is for enabling the feature |
there is only one code reference in https://grep.app/search?q=LegacyServiceAccountTokenNoAutoGeneration%3Dfalse. according to Azure/aks-engine#4890 (comment), that will not be supported in 1.25+; others are markdown files. |
not sure about this one. couldn't find any owners on this file.
seems these windows testing files were requiring the feature gate disabled due to the legacy aks-engine, which will not be supported in 1.25+ per last comment. @marosset to confirm since you authored the relevant PRs. |
aks-engine was on life-support during v1.24 and is now deprecated. Because of that we opted to just disable to feature for v1.24 clusters used to run Windows e2e tests and I didn't go very deep into understanding what was actually failing. Since the deprecation of aks-engine - all of the Windows e2e tests that were running on aks-engine have been migrated to CAPZ and we do not have this feature disabled for any of the CAPZ clusters. |
I don't remember the specific error, but we were unable to provision new clusters with the new behavior, so I enabled the legacy flag in Azure/aks-engine#4890. |
so the 1.25 tests don't need to disable the feature gate? in other words, this pr has no impact on your tests |
In our specific case (AKS Engine), the product is deprecated and will never support v1.25. So that made enabling the legacy behavior justifiable. |
@liggitt any other cases we need to figure out before merging this PR? |
Does this PR need a release note? |
I'm satisfied that the controller itself is stable with the gate off, so I think promoting it to GA in 1.26 is reasonable. I'd probably wait to lock it on until 1.23 is no longer supported, to ensure all supported clusters have encountered the feature gate in 1.24 and made plans to adjust to use tokenrequest or explicitly request secrets, and given feedback on the change. |
i couldn't recall a feature that can be disabled in GA (without lock). in most scenarios, a cluster will not jump version when upgrading. so mostly they will have two releases to make plans before upgrading to 1.26 (locked). the question comes down to how many releases are we comfortable with. |
Both of those boundaries seem good to me. |
concretely, that's in ~Feb 2023, so in time for 1.27 (https://kubernetes.io/releases/patch-releases/#1-23) |
go ahead and scope this PR to promoting the feature gate to GA, and plan to lock it on in 1.27 |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, zshihang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
What type of PR is this?
/kind feature
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: