k8s-ci-robot
commented
1 year ago @x13n: This request has been marked as needing help from a contributor.
Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- Does this issue have zero to low barrier of entry?
- How can the assignee reach out to you for help?
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
by commenting with the /remove-help command.
In response to [this](https://github.com/kubernetes/autoscaler/issues/5432):
>
>**Which component are you using?**:
>
>cluster-autoscaler
>
>**Is your feature request designed to solve a problem? If so describe the problem this feature should solve.**:
>
>Enabling new features in Cluster Autoscaler usually requires a feature flag. Existing examples include `--scale-down-enabled` (sic!), `--debugging-snapshot-enabled` or `--parallel-drain`. These flags contribute to an already existing huge API surface of Cluster Autoscaler flags. Additionally, implementation of such flags sometimes requires passing them through a few layers of abstraction (e.g. through `AutoscalingOptions`), making the code harder to maintain.
>
>**Describe the solution you'd like.**:
>
>There should be a single flag to control feature enablement. Feature flags should be accessible from the code - they are global to the entire CA process anyway. I'd reuse the approach taken in kube-apiserver: http://go/kuber/blob/1ca2180f300bb83e4581c7efb02ab91b7027b6f3/staging/src/k8s.io/apiserver/pkg/util/feature/feature_gate.go#L32
>
>**Describe any alternative solutions you've considered.**:
>
>Build a custom mechanism for this. On one hand we don't really need all the alpha/beta/GA in Cluster Autoscaler, but it will be simpler to reuse what is already there (especially since CA already takes a dependency on core k8s).
>
>**Additional context.**:
>
>/help
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
guopeng0
x13n
Which component are you using?:
cluster-autoscaler
Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:
Enabling new features in Cluster Autoscaler usually requires a feature flag. Existing examples include
--scale-down-enabled(sic!),--debugging-snapshot-enabledor--parallel-drain. These flags contribute to an already existing huge API surface of Cluster Autoscaler flags. Additionally, implementation of such flags sometimes requires passing them through a few layers of abstraction (e.g. throughAutoscalingOptions), making the code harder to maintain.Describe the solution you'd like.:
There should be a single flag to control feature enablement. Feature flags should be accessible from the code - they are global to the entire CA process anyway. I'd reuse the approach taken in kube-apiserver: http://go/kuber/blob/1ca2180f300bb83e4581c7efb02ab91b7027b6f3/staging/src/k8s.io/apiserver/pkg/util/feature/feature_gate.go#L32
Describe any alternative solutions you've considered.:
Build a custom mechanism for this. On one hand we don't really need all the alpha/beta/GA in Cluster Autoscaler, but it will be simpler to reuse what is already there (especially since CA already takes a dependency on core k8s).
Additional context.:
/help