feat: support for feature gates #1146
Conversation
github-actions
bot
added
kind/feature
| // Default behavior is to be enabled if entry is given | ||
| // for a feature name and mode is not equal *off*. | ||
| type FeatureGate struct { | ||
| Mode string `json:"mode"` |
There was a problem hiding this comment.
Generally in favor of this, but why choose to have a Mode setting for the Gate if you already have attributes? Shouldn't the mere presence of the gate determine if its enabled or disabled?
There was a problem hiding this comment.
The idea of the mode is to have a fixed/non-optional config field usable to enable/disable a feature and control an implementation mode (if required). The value off is always used to enforce disabling the feature (in case it is enabled by default).
The attributes are completely optional and intended to pass arbitrary information to the feature. (An on/off switch does not use attributes at all (omitempty))
There was a problem hiding this comment.
The idea of the mode is to have a fixed/non-optional config field usable to enable/disable a feature and control an implementation mode (if required). The value off is always used to enforce disabling the feature (in case it is enabled by default).
Could you give me an example for an "implementation mode" that is not on/off? Ive never seen it anywhere in production and was assuming that even if there was a non on/off, it would be part of the attributes.
| type FeatureGate = featuregatesattr.FeatureGate | ||
|
|
||
| // Config describes a memory based repository interface. | ||
| type Config struct { |
There was a problem hiding this comment.
Whats the reason to have a config and an attribute set, shouldnt attributes alone be enough?
github-actions
bot
added
the
component/github-actions
| // Sort is a processing chain sorting original objects provided by type handler. | ||
| var Sort = processing.Sort(Compare) |
cmds/ocm/commands/ocmcmds/common/handlers/featurehdlr/suite_test.go
Outdated
Show resolved
Hide resolved
github-actions
bot
added
area/documentation
cmds/ocm/commands/ocmcmds/common/handlers/featurehdlr/typehandler_test.go
Outdated
Show resolved
Hide resolved
What this PR does / why we need it
This PR introduces the concept of feature gates for the OCM library/CLI.
A feature has a name and a setting.
The standard setting is a
modevalue. Setting the mode tooffenforces the feature to be disabled.All other mode values enable the feature and can be used by the implementation to select the way it is supported.
If a feature is not explicitly configured to have a setting it is assumed to be disabled by default.
Optionally, settings may include a arbitrary set of name/value pairs, a value might be structured.
A feature may be enabled or disabled by default, depending of the arguments to the
feature query functions.
The set of feature gates can be set on context-level by a context attribute
ocm.software/ocm/feature-gateswith the short namefeaturegates.Additionally, a dedicated config object is provided (
featuregates.config.ocm.software).It supports the following config fields:
features: map[string]FeatureGatemap of feature settingsA
FeatureGatehas the fields:mode: string if set toofffeatures is enforced to be disabled. Other values enable the featureattributes: map[string]<any json/yaml> optional named feature settingsWhich issue(s) this PR fixes