You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 10, 2023. It is now read-only.
With #3665 getting merged soon, we will have decoupled the Feature-Flags from the cli/runtime library and moved them into plugin specific code. The idea is that plugins should specify their feature-flags themselves, and the core CLI will then store them in the config file.
However we should not let plugins define the entire feature-flag path for their flags. It gives them too much control over where flags will be stored. They should only be able to specify a subpath under features.<pluginName>, and it should be the CLI that prepends the fixed features.<pluginName> prefix. Currently, by being able to specify the entire path, a plugin could create or modify feature-flags for other plugins or even for the core CLI.
For example, the feature-flag features.management-cluster.standalone-cluster-mode should only be defined as standalone-cluster-mode by the management-cluster plugin and passed that way to the CLI in the PluginDescriptor. The CLI would then add the features.management-cluster prefix before storing it in the config file.
Affected product area (please put an X in all that apply)
(x) APIs
( ) Addons
( ) CLI
( ) Docs
( ) IAM
( ) Installation
(x) Plugin
( ) Security
( ) Test and Release
( ) User Experience
( ) Developer Experience
Additional info
Note that the features.global.tkr-version-v1alpha3-beta and features.global.package-based-lcm-beta are "global" feature-flags, but are created by plugins. This is something that would need to be fixed to be able to properly address the current issue.
This issue would benefit in being fixed before the cli-runtime lib or the plugins are split away from Framework so that we could make the change everywhere at once.
The text was updated successfully, but these errors were encountered:
Describe the feature request
With #3665 getting merged soon, we will have decoupled the Feature-Flags from the
cli/runtime
library and moved them into plugin specific code. The idea is that plugins should specify their feature-flags themselves, and the core CLI will then store them in the config file.However we should not let plugins define the entire feature-flag path for their flags. It gives them too much control over where flags will be stored. They should only be able to specify a subpath under
features.<pluginName>
, and it should be the CLI that prepends the fixedfeatures.<pluginName>
prefix. Currently, by being able to specify the entire path, a plugin could create or modify feature-flags for other plugins or even for the core CLI.For example, the feature-flag
features.management-cluster.standalone-cluster-mode
should only be defined asstandalone-cluster-mode
by themanagement-cluster
plugin and passed that way to the CLI in the PluginDescriptor. The CLI would then add thefeatures.management-cluster
prefix before storing it in the config file.This came out of this discussion: #3665 (comment)
Describe alternative(s) you've considered
Affected product area (please put an X in all that apply)
Additional info
Note that the
features.global.tkr-version-v1alpha3-beta
andfeatures.global.package-based-lcm-beta
are "global" feature-flags, but are created by plugins. This is something that would need to be fixed to be able to properly address the current issue.This issue would benefit in being fixed before the
cli-runtime
lib or the plugins are split away from Framework so that we could make the change everywhere at once.The text was updated successfully, but these errors were encountered: