diff --git a/design/feature-flags.md b/design/feature-flags.md new file mode 100644 index 000000000..b6382c64f --- /dev/null +++ b/design/feature-flags.md @@ -0,0 +1,71 @@ +# Feature Flags + +Status: Accepted + +Some features may take a while to get fully implemented, and we don't necessarily want to have long-lived feature branches +A simple feature flag implementation allows code to be merged into master, but not used unless a flag is set. + +## Goals + +- Allow unfinished features to be present in Velero releases, but only enabled when the associated flag is set. + +## Non Goals + +- A robust feature flag library. + +## Background + +When considering the [CSI integration work](https://github.com/heptio/velero/pull/1661), the timelines involved presented a problem in balancing a release and longer-running feature work. +A simple implementation of feature flags can help protect unfinished code while allowing the rest of the changes to ship. + +## High-Level Design + +A new command line flag, `--features` will be added to the root `velero` command. + +`--features` will accept a comma-separated list of features, such as `--features EnableCSI,Replication`. +Each feature listed will correspond to a key in a map in `pkg/features/features.go` defining whether a feature should be enabled. + +Any code implementing the feature would then import the map and look up the key's value. + +For the Velero client, a `features` key can be added to the `config.json` file for more convenient client invocations. + +## Detailed Design + +A new `features` package will be introduced with these basic structs: + +```go +type FeatureFlagSet struct { + flags map[string]bool +} + +type Flags interface { + // Enabled reports whether or not the specified flag is found. + Enabled(name string) bool + + // Enable adds the specified flags to the list of enabled flags. + Enable(names ...string) + + // All returns all enabled features + All() []string +} + +// NewFeatureFlagSet initializes and populates a new FeatureFlagSet +func NewFeatureFlagSet(flags ...string) FeatureFlagSet +``` + +When parsing the `--features` flag, the entire `[]string` will be passed to `NewFeatureFlagSet`. +Additional features can be added with the `Enable` function. +Parsed features will be printed as an `Info` level message on server start up. + +No verification of features will be done in order to keep the implementation minimal. + +On the client side, `--features` and the `features` key in `config.json` file will be additive, resulting in the union of both. + +To disable a feature, the server must be stopped and restarted with a modified `--features` list. +Similarly, the client process must be stopped and restarted without features. + +## Alternatives Considered +Omitted + +## Security Considerations +Omitted