Feature gate implementation and documentation #4108
Conversation
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
Moves the implementation from `config/configgates` to `service.featuregate`. Rearranges CLI flag handling so that it is all performed by a ParserProvider and the ConfigUnmarshaler does not need to know about CLI flags. Removes `Registry` type, collapsing `frozenRegistry` to `registry` and putting `Register()` and `Apply()` functions at the package scope. Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
Codecov Report
@@ Coverage Diff @@
## main #4108 +/- ##
==========================================
+ Coverage 87.65% 87.70% +0.04%
==========================================
Files 173 174 +1
Lines 10265 10305 +40
==========================================
+ Hits 8998 9038 +40
Misses 1015 1015
Partials 252 252
Continue to review full report at Codecov.
|
…tor into feature_gates_pt1
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
…tor into feature_gates_pt1
…tor into feature_gates_pt1
…tor into feature_gates_pt1
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
|
Following discussion with @bogdandrutu this has been stripped down to the minimal implementation of a global feature gate registry with exported accessor and mutator functions. We felt that this is the simplest approach and best suited to minimizing impact to the API of packages that wish to utilize feature gates. Configuration of the gates by CLI flag, environment variable, and possibly a separate feature gates config file will follow in a future PR. |
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
|
Kubernetes feature-gate implementation links, as requested at the meeting today: |
…tor into feature_gates_pt1
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
|
I left a comment on a resolved discussion #4108 (comment) because I want to understand why the global registry approach was favored. I don't get which uses cases won't be supported by the other suggested approach in that conversation. |
| var reg = ®istry{gates: make(map[string]Gate)} | ||
|
|
||
| // IsEnabled returns true if a registered feature gate is enabled and false otherwise. | ||
| func IsEnabled(id string) bool { |
There was a problem hiding this comment.
@Aneurysm9 maybe as a prototype after this PR is merged, we can give a try to have the "Registry" public, with the equivalent funcs on it, and have only a "GetRegistry" func that gets the global one. This way for testing users can pass a "non-global" registry in their code, so limit the interaction with the global state.
@Aneurysm9 just to confirm, are you working on the PR that adds the gates CLI flag? |
Yes, working on that now and I should have a PR up later today or tomorrow. |
Signed-off-by: Anthony J Mirabella a9@aneurysm9.com
Description: Splits the feature gate system from #4103. This is the feature gate library in isolation, along with documentation describing how it is to be used.