Conversation
Introduces an ExperimentalFeature enum and feature_flags config to allow toggling experimental features via the supervisor options API. The first feature flag is 'supervisor_v2_api' to gate the upcoming V2 API. Absent keys in options request = no change (partial update, consistent with existing options APIs). The info endpoint always returns all known feature flags and their current state for discoverability. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
So first thing I realized with the v2 API is I want us to be able to iterate on it for a bit. And I don't want to block Supervisor releases until its ready to ship to make changing what we have a breaking change. So I thought a feature toggle setup would be a good idea. Then we can continue to ship versions of Supervisor as normal while freely changing V2 until its ready without worrying about breaking others. |
agners
left a comment
agners
left a comment
There was a problem hiding this comment.
Other than the naming nit, I think this is a good idea. In a way it mirrors a bit the lab approach we have in Core. The incremental development approach works much better for us, and having the feature behind a flag helps us avoid features being used while they are work-in-progress. Nice 👍 !
| vol.Optional(ATTR_DETECT_BLOCKING_IO): vol.Coerce(DetectBlockingIO), | ||
| vol.Optional(ATTR_COUNTRY): str, | ||
| vol.Optional(ATTR_FEATURE_FLAGS): vol.Schema( | ||
| {vol.Coerce(ExperimentalFeature): vol.Boolean()} |
There was a problem hiding this comment.
The flag is named feature_flags, the enum ExperimentalFeature. I'd prefer if we have either experimental in both of them or none of them.
I guess the later would potentially be misunderstood, or rather change the scope of this feature flag 🤔 .
There was a problem hiding this comment.
Good point. I think I'll just go with the industry standard feature flag term rather then impose a use case on them with experimental
mdegat01
added
missing-documentation
2 participants
Summary
Adds a feature toggle system to Supervisor to gate experimental features during development, preventing users from depending on in-flux APIs.
The first toggle is
supervisor_v2_apiwhich will gate the upcoming V2 API.API Changes
POST /supervisor/optionsAccepts a
feature_flagsdict. Only keys present are changed — absent keys leave the current state unchanged, consistent with Supervisor's existing partial-update pattern.{"feature_flags": {"supervisor_v2_api": true}}Unknown feature flag names are rejected with a 400 error.
GET /supervisor/infoAlways returns all known feature flags and their current state for discoverability:
{"feature_flags": {"supervisor_v2_api": false}}Implementation
ExperimentalFeatureStrEnum insupervisor/const.py— add new toggles here as an enum valuefeature_flagsstored inconfig.jsonas a dict, defaults toFalsefor any flag not yet setExperimentalFeatureenum values