Skip to content
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

[CompatibilityVersion] Unconventional use of feature gates #130547

Open
siyuanfoundation opened this issue Mar 3, 2025 · 3 comments
Open

[CompatibilityVersion] Unconventional use of feature gates #130547

siyuanfoundation opened this issue Mar 3, 2025 · 3 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/node Categorizes an issue or PR as relevant to SIG Node. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@siyuanfoundation
Copy link
Contributor

Throughout the code base, instead of just using the feature gates to check if a feature is enabled or not, there are several unconventional use of feature gates:

  • LoggingAlphaOptions: {Default: false, PreRelease: featuregate.Alpha},
    LoggingBetaOptions: {Default: true, PreRelease: featuregate.Beta},
    are used to promote new format options configurable.
  • CPUManagerPolicyAlphaOptions featuregate.Feature = "CPUManagerPolicyAlphaOptions"
    // owner: @fromanirh
    // beta: see below.
    //
    // Allow fine-tuning of cpumanager policies, experimental, beta-quality options
    // Per https://groups.google.com/g/kubernetes-sig-architecture/c/Nxsc7pfe5rw/m/vF2djJh0BAAJ
    // We want to avoid a proliferation of feature gates. This feature gate:
    // - will guard *a group* of cpumanager options whose quality level is beta.
    // - is thus *introduced* as beta
    // - will never graduate to stable.
    // See https://groups.google.com/g/kubernetes-sig-architecture/c/Nxsc7pfe5rw/m/vF2djJh0BAAJ
    // for details about the removal of this feature gate.
    CPUManagerPolicyBetaOptions featuregate.Feature = "CPUManagerPolicyBetaOptions"
    // owner: @fromanirh
    //
    // Allow the usage of options to fine-tune the cpumanager policies.
    CPUManagerPolicyOptions featuregate.Feature = "CPUManagerPolicyOptions"
    are used to allow for new options to fine-tune the cpumanager policies
  • TopologyManagerPolicyAlphaOptions featuregate.Feature = "TopologyManagerPolicyAlphaOptions"
    // owner: @PiotrProkop
    // kep: https://kep.k8s.io/3545
    //
    // Allow fine-tuning of topology manager policies with beta options.
    // This feature gate:
    // - will guard *a group* of topology manager options whose quality level is beta.
    // - is thus *introduced* as beta
    // - will never graduate to stable.
    TopologyManagerPolicyBetaOptions featuregate.Feature = "TopologyManagerPolicyBetaOptions"
    // owner: @PiotrProkop
    // kep: https://kep.k8s.io/3545
    //
    // Allow the usage of options to fine-tune the topology manager policies.
    TopologyManagerPolicyOptions featuregate.Feature = "TopologyManagerPolicyOptions"
    are used to allow for new options to fine-tune the topology manager policies.

These feature gate do not progress in lifecycle, while the underlying available options progress over the stages.
As it is right now, we would not be able to emulate these options in compatibility mode. For example, if a new option is moved from Beta to GA feature from 1.32 to 1.33, this option would be available as a GA option when we are emulating 1.32.

Ideally, we would want these new options to be tracked by a dedicated feature gate for each option.
If that's not feasible, we would need a mechanism to track when these options are moved from one stage to another.
Otherwise, these options are not emulatible, and we will always have the options at the binary version, even when the emulation version is different.

@k8s-ci-robot k8s-ci-robot added needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Mar 3, 2025
@siyuanfoundation
Copy link
Contributor Author

/cc @yongruilin
/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Mar 3, 2025
@thisisharrsh
Copy link

/sig node
/sig architecture

@k8s-ci-robot k8s-ci-robot added sig/node Categorizes an issue or PR as relevant to SIG Node. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Mar 4, 2025
@thisisharrsh
Copy link

/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/node Categorizes an issue or PR as relevant to SIG Node. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

3 participants