-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Add --feature-gates
flag to support scale up on volume limits (CSI migration enabled)
#4539
Add --feature-gates
flag to support scale up on volume limits (CSI migration enabled)
#4539
Conversation
…migration enabled) Signed-off-by: ialidzhikov <[email protected]>
Can you please paste what would --help output look like with this PR? |
Help output
|
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ialidzhikov, MaciekPytel 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 |
@ialidzhikov would we want to cherry-pick this backwards to 1.21? I know we just released patches there but maybe for the next round of patches. |
|
…539-upstream-cluster-autoscaler-release-1.21 [release-1.21] Automated cherry pick of #4539: Add `--feature-gates` flag to support scale up on volume
…539-upstream-cluster-autoscaler-release-1.22 [release-1.22] Automated cherry pick of #4539: Add `--feature-gates` flag to support scale up on volume
…539-upstream-cluster-autoscaler-release-1.20 [release-1.20] Automated cherry pick of #4539: Add `--feature-gates` flag to support scale up on volume
/kind bug
/sig autoscaling
/sig storage
What this PR does / why we need it:
This PRs adds a
--feature-gates
flag to the cluster-autoscaler. For more details on why this is needed see #4517.Which issue(s) this PR fixes:
Fixes #4517
Special notes for your reviewer:
This approach has the small drawback that it adds all K8s feature gates as known ones (which makes the
--help
output verbose and misleading).On the other side, with this approach we receive the list of known feature gates and their default values from the upstream (by vendoring clster-autoscaler) -> no need to manually maintain out custom list with upstream feature gates and their defaults.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: