runtime feature guarding #5693
Comments
alyssawilk
added
enhancement
This was referenced Jan 23, 2019
alyssawilk
added a commit
that referenced
this issue
Feb 13, 2019
Adding hooks for phase 2 of deprecation: fail-by-default features, and runtime overrides. _Risk Level_: Low (minimal refactors to core code) _Testing_: new unit tests TODO more tests _Docs Changes_: TODO docs on deprecation process _Release Notes_: n/a - will add a release note when we add existing config to deprecated Part of #5559 and #5693 Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
fredlas
pushed a commit
to fredlas/envoy
that referenced
this issue
Mar 5, 2019
Adding hooks for phase 2 of deprecation: fail-by-default features, and runtime overrides. _Risk Level_: Low (minimal refactors to core code) _Testing_: new unit tests TODO more tests _Docs Changes_: TODO docs on deprecation process _Release Notes_: n/a - will add a release note when we add existing config to deprecated Part of envoyproxy#5559 and envoyproxy#5693 Signed-off-by: Alyssa Wilk <alyssar@chromium.org> Signed-off-by: Fred Douglas <fredlas@google.com>
alyssawilk
added a commit
that referenced
this issue
Mar 13, 2019
Documenting best practices and adding some tooling for guarding high risk features Risk Level: Low (mostly new code) Testing: Added new unit tests Docs Changes: updated CONTRIBUTING.md Release Notes: n/a Part of #5693 (TODO: handling deprecating and adding tooling scripts) Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
@alyssawilk should we consider this issue done for the initial version? Or is there more work to do that we want to track here? |
|
There's 1-2 TODOs left - handling deprecation as we do for deprecated protos, and adding a sweep of our code + auto-fatal-ification to the release scripts to make it "safe" to remove old code paths. |
|
@alyssawilk sg. Should we move to 1.11.0 milestone and finish it up there? |
|
I don't know that anyone pays attention to milestones but I guess the feature flips are done here, and deprecation will be done in the next release when we might have features to deprecate :-P. Filed a new issue and I'll close this off |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Per discussion over on #5441 it'd be good to have a globally accessible framework guarding high risk features, as well as tooling to handle the lifetime of migration from old code to new, which matches what we do for config guarding including warning/hard-fail (see #5559) and scripts to advance from warning to defaut-off to filing clean-up issues.
Plan A is to use Envoy's existing run-time, but make it a singleton to make it easy for any code in Envoy to check in on the status of the relevant features.
Eventually it'd be nice if flags could also pulled over a discovery service, as well as set via command line for those of us who are used to flag based features
This issue covers both the code changes and tooling changes as one without the other isn't particularly usable.
I'm going to stick this on the agenda for next week's community meeting, but I'd appreciate folks in the community and @envoyproxy/maintainers weighing in early and often with thoughts of how to make this useful and easy to use.
The text was updated successfully, but these errors were encountered: