[CompatibilityVersion] Unconventional use of feature gates #130547
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.
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:
kubernetes/staging/src/k8s.io/component-base/logs/api/v1/kube_features.go
Lines 64 to 65 in df030f3
kubernetes/pkg/features/kube_features.go
Lines 98 to 116 in df030f3
kubernetes/pkg/features/kube_features.go
Lines 684 to 700 in df030f3
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.
The text was updated successfully, but these errors were encountered: