Propose adding feature flags to velero
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>pull/1759/head
parent
1670aa17b6
commit
38643f2f4a
|
@ -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
|
Loading…
Reference in New Issue