Feature Flags #508
Feature Flags #508
Conversation
Signed-off-by: Sarah McClure <[email protected]>
Signed-off-by: Sarah McClure <[email protected]>
smcclure20
had a problem deploying
to
functional-tests
GitHub Actions
Failure
| client := paragliderpb.NewCloudPluginClient(conn) | ||
| cloudFlags := ¶gliderpb.PluginFlags{KubernetesClustersEnabled: cfg.FeatureFlags.PluginFlags[c.Name].KubernetesClustersEnabled, | ||
| PrivateEndpointsEnabled: cfg.FeatureFlags.PluginFlags[c.Name].PrivateEndpointsEnabled} | ||
| _, err = client.SetFlags(context.Background(), ¶gliderpb.SetFlagsRequest{Flags: cloudFlags}) |
There was a problem hiding this comment.
missing logging or returning err?
pkg/orchestrator/config/config.go
Outdated
| AttachResourceEnabled bool `yaml:"attachResourceEnabled"` | ||
| } | ||
|
|
||
| type PluginFlags struct { |
There was a problem hiding this comment.
Did you consider having a flat struct containing all feature flags? I think I like the simplicity of it, plus it doesn't prevent use from having a feature flag that both orchestrator and plugins need to reason about.
There was a problem hiding this comment.
I did, and this may be a good change to make. However, I went with this direction since it makes it extremely clear which ones the plugin developer is responsible for. Otherwise, they may implement some logic for a flag that will only ever be used in the orchestrator. Happy to discuss more though.
Signed-off-by: Sarah McClure <[email protected]>
Signed-off-by: Sarah McClure <[email protected]>
Signed-off-by: Sarah McClure <[email protected]>
smcclure20
requested a deployment
to
functional-tests
GitHub Actions
Waiting
|
For the detailed report, please go to
|
Signed-off-by: Sarah McClure <[email protected]>
smcclure20
requested a deployment
to
functional-tests
GitHub Actions
Waiting
|
For the detailed report, please go to
|
TODO:
Resolves #506