-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #1335: add general-purpose Feature flag system #1390
Conversation
Ready for initial review: need to think about how this could be tested better. |
…PPER CASE in Enum name)
src/main/java/io/stargate/sgv2/jsonapi/service/cqldriver/executor/NamespaceCache.java
Show resolved
Hide resolved
src/main/java/io/stargate/sgv2/jsonapi/api/request/DataApiRequestInfo.java
Show resolved
Hide resolved
} | ||
|
||
/** | ||
* Accessor for getting value of given header (case-insensitive), as {@code Boolean} if (and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: does the case insensitivity come from the io.vertx.core.MultiMap ? assuming yes, and that this is because of the HTTP standard, can we make that clear because there is nothing in this code enforcing that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, is due to vertx http server impl that does it for HTTP standard reason.
What I am thinking is that we only document use of lower-case header name for usage, and leave ability for case-insensitivity as impl detail: this since we are not exposing features to actual end users. If case-insensitivity wasn't provided I wouldn't bother actually adding it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmh. While I'd prefer all lower-case, looks like general best practice seems to be mixed case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am on the edge of my seat here, seems to be ??? seems to be...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmmh. Not sure why your GUI showed "seems to be" without second line ("mixed case"). Or is that secret line just shown to me? :-o
(I saw it missing when you screen shared)
src/main/java/io/stargate/sgv2/jsonapi/config/feature/DataApiFeatureConfig.java
Outdated
Show resolved
Hide resolved
|
||
private final String featureName; | ||
|
||
private final boolean enabledByDefault; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The command above says "If no configuration specified (config or request), the feature will be Disabled."
consider: we should prob enforce this by default in the enum and remove the enabledByDefault setting. Concern would be that we end up with a mix of values and it gets confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Problem is that precedence is 3-layered:
- Explicit value from FeaturesConfig (map keyed by feature)
- Explicit value from request header if no (1)
- Default if neither (1) or (2).
I originally thought of just leaving (3) to be false
for simplicity; I can still do that and drop enabledByDefault
as it is not strictly needed -- and can be added if/when needed (or something else that does what is needed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussed - drop the enabledByDefault and always default to false. the mental model is these are named boolean values, that default to false.
src/main/java/io/stargate/sgv2/jsonapi/config/feature/DataApiFeatureFlag.java
Outdated
Show resolved
Hide resolved
src/main/java/io/stargate/sgv2/jsonapi/config/feature/DataApiFeatures.java
Outdated
Show resolved
Hide resolved
// First check if there is definition from configuration | ||
Boolean b = fromConfig.get(flag); | ||
|
||
if (b == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if I read this correctly, if the feature is disabled in config it is not possible to enable via request. You mention the three ways for controlling features the other day, may be best to spell this out very clearly at the top fo this class.
src/main/java/io/stargate/sgv2/jsonapi/service/cqldriver/executor/NamespaceCache.java
Show resolved
Hide resolved
src/main/resources/application.yaml
Outdated
@@ -25,6 +25,10 @@ stargate: | |||
exception-mappers: | |||
enabled: false | |||
|
|||
feature: # See io.stargate.sgv2.jsonapi.config.feature.DataApiFeatureConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not: can we expand the docs here, or point to expanded docs on the DataApiFeatures class to explain the logic for setting values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed link wrt name, but thinking of documenting only/mostly on code side.
@@ -40,15 +41,21 @@ public final class TestConstants { | |||
|
|||
// CommandContext for working on the schema objects above | |||
|
|||
public static final DataApiFeatures DEFAULT_API_FEATURES_FOR_TESTS = DataApiFeatures.empty(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question - how easy / desirable is it to be able to turn on features in a DataApiFeatures class so we can run unit test without needing the things the happen in the DseTestResource class ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking that using DseTestResource
reflects actual usage better, and as long as we do not have tons of testing for alternative setting (that is, most tests can use specific default), works for now.
Otherwise we may end up adding test scaffolding that differs from actual running.
This wrt ITs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally like where this is going, just comments on names and some details.
Ok: situation at the end of week:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
reviewed in person, Done for me . Will approve, and then we need to get the error object V2 flag to use features config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved, see last comment
Last changes; will merge once CI passes. |
What this PR does:
Adds extensible Feature-Flag system to allow both default, system prop setting, and per-request overrides.
Initially just a single feature is added, "tables":
stargate.feature.flags.tables
Feature-Flag-tables
(case-insensitive)That is: when starting; may specific fixed enabled/disabled via
application.yaml
or system property; latter like:but if no setting specified (and ONLY in that case), per-request
curl
header like:can be used to enable/disable processing
Which issue(s) this PR fixes:
Fixes #1355
Checklist