2.4 KiB
#+Title:Cisco Epic Feature Flag by Env
Feature Flag by Env TOC_3_gh QUOTE
Requirement
> Craig Brozefsky Yesterday, 17:04 > Matt: No orgs in EU should have devices scope
Current status
Until now we managed feature flag for an entire release. As such the feature-flag was 100% held in the code, not in the deployement conf.
There are two methods used until today to manage feature-flags:
- scopes
- service launch (in bootstrap.cfg)
- control via config (in config.edn)
The current requirement only talks about the sse scope.
In fact we could (should) also prevent the sse-service to be launched.
Note that scope handling is generally not trivial:
- CTR use the scope as the single dimension to handle authorizations. One consequence is that the notion of role is not really meaningful in the CTR code. The role is only used from the info provided by the IdP and then interpreted as a set of scopes (which can change dynamically, for exemple we can attribute additional scopes to some org or user). It is also planned to provide the ability for admin users to change the scopes of other users of their org.
Proposed Solution.
Feature Flag Block in config.edn
That way it would be possible to not only handle scopes but also manage the feature flag in some specific part of the code. Typically we could use that flag to ignore some conf, and to not initialize fully some service.
Service Launch Handling
- If a service is started but its presence is not necessary when the feature flag is off. The service should not really init itself fully and only return a nil context and the methods should also returns nil silently
Scope Handling
Depending of the feature flag we might add an additional step during login we might "add" some new scopes and "remove some". If that's the case we might also change the JWT version dyamically.
I would suggest something like:
(defn dyn-jwt-version [activated-features]
(string/join "-" (cons static-jwt-version activated-features))
That would produce version such as: v1.23, v1.23-sse, v1.23-sse-scim,
etc…