-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
route match: Add runtime_fraction field for more granular routing #4217
route match: Add runtime_fraction field for more granular routing #4217
Conversation
64d1488
to
2f063e1
Compare
source/common/json/config_schemas.cc
Outdated
@@ -689,6 +689,27 @@ const std::string Json::Schema::ROUTE_ENTRY_CONFIGURATION_SCHEMA(R"EOF( | |||
"required" : ["key", "default"], | |||
"additionalProperties" : false | |||
}, | |||
"runtime_fraction" : { |
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.
remove this, backport to v1 is not required
Signed-off-by: Tony Allen <tallen@lyft.com>
2f063e1
to
9490c37
Compare
Just FYI- looks like my api check has fallen victim to #4218. Everything else is in good working order though. |
api/envoy/type/percent.proto
Outdated
|
||
// Runtime derived FractionalPercent with defaults for when the numerator or denominator is not | ||
// specified via a runtime key. | ||
message RuntimeFractionalPercent { |
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.
can we move this back into route.proto or create a runtime proto? i don't think percent.proto should contain this runtime concept.
source/common/router/config_impl.cc
Outdated
data.numerator_key_ = route_match.runtime_fraction().numerator_runtime_key(); | ||
data.numerator_default_ = route_match.runtime_fraction().default_value().numerator(); | ||
|
||
const std::string& d_key = route_match.runtime_fraction().denominator_runtime_key(); |
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: spell out d_
prefix
api/envoy/type/percent.proto
Outdated
FractionalPercent default_value = 1 [(validate.rules).message.required = true]; | ||
|
||
// Runtime key to get numerator value for comparison. This value is used if defined. | ||
string numerator_runtime_key = 2; |
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 think you could safely shorten these to numerator_key, denominator_key since they're already under runtime_fraction. up to you.
looking good. minor comments. |
Signed-off-by: Tony Allen <tallen@lyft.com>
@ggreenway just FYI, that circleci API check failure has nothing to do with my PR- it's due to #4218. In case you were holding off on the review due to the check failure. |
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.
Looks pretty good. I have one question about the behavior when the denominator key lookup fails to produce a valid denominator.
Unfortunately, I'm headed out of town until Tuesday, so another maintainer will have to pick this up if you want to get it merged before then.
source/common/router/config_impl.cc
Outdated
FractionalPercent::DenominatorType denominator_type; | ||
if (!FractionalPercent::DenominatorType_Parse(denominator_data, &denominator_type)) { | ||
denominator_type = route_match.runtime_fraction().default_value().denominator(); | ||
} |
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 right, failure to convert the denominator key into a valid denominator value causes us to use the numerator key's value with the default value's denominator. That seems like it might cause some pretty unexpected behavior. Is it reasonable to just switch using the default value altogether in this 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 think what you propose is the sane thing to do. I'll change the logic.
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.
Actually- scratch that. A user would have unexpected behavior either way if they misspell a denominator type and it switches to a default value. I'm not sure one way is better than the other. @htuch what do you think?
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 sure what the best practice to alert when runtime is wrong; how do folks operationally determine when a runtime change has taken effect? Via /runtime
?
One thought that occurred to me just now is that instead of having separate values for numerator/denominator, we have a single values, which is a textual representation of a FractionalPercent
proto. That way, we can just use PGV validation on this to check sanity. It also solves an update atomicity issue.
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
api/envoy/type/runtime_percent.proto
Outdated
// Default value if the runtime value's for the numerator/denominator keys are not available. | ||
envoy.type.FractionalPercent default_value = 1 [(validate.rules).message.required = true]; | ||
|
||
// Runtime key for a textual representation of a :ref:`fractional percent |
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.
Nice to see this approach. I actually think we should use the JSON/YAML encoding on second thoughts, since text proto is not a standard. If you go this route, we have some helpers to make it easy to parse, see https://github.com/envoyproxy/envoy/blob/master/source/common/protobuf/utility.h#L210. This will also validate the proto for you for constraints, which is missing in the parsing below.
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
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.
Looks great, two final minor comments (and the api
build looks still broken).
api/envoy/type/runtime_percent.proto
Outdated
|
||
// Runtime derived FractionalPercent with defaults for when the numerator or denominator is not | ||
// specified via a runtime key. | ||
message RuntimeFractionalPercent { |
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.
Should this be in api/envoy/api/v2/core/base.proto
so as to be next to RuntimeUint32
?
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 didn't do that because I didn't want to introduce a dependency on percent.proto. It was originally in percent.proto, but an earlier comment from @danielhochman suggested I move it out into its own file.
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.
It's fine for base to depend on percent.proto (just not the other way around).
Signed-off-by: Tony Allen <tallen@lyft.com>
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.
Looks great, thanks!
Oh crap, we're hitting the PGV CLI issue in the Mac build (CC @zuercher). I think this is solved due to some nice work done by @sesmith177 in fixing this in PGV, but we're still blocked on importing this into Envoy due to PG* issues. I think @rodaine suggested we might see this progress this week. It might be possible to trick the build into passing in the meanwhile by doing something hacky to make the PGV dependencies have a shorter CLI, but if you can wait a few days maybe this problem sorts itself out... |
That's fine, it's not a super high-priority for us at the moment. I'm assuming it'll be fixed in the next week or two? Let me know if I can help in any way. |
@tonya11en you'll need to merge master to pick up that change; if you do that and push the CI will rerun. |
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
…ting (envoyproxy#4217)" This reverts commit 75e54d0. This was breaking Mac CI due to known PGV CLI limits. Signed-off-by: Harvey Tuch <htuch@google.com>
@tonya11en do you want to try rolling this forward now that #4551 has merged? Sorry about all this futz, if we hit PGV issues still I can now go and fix them. |
…voyproxy#4217) Signed-off-by: Tony Allen <tallen@lyft.com>
) This patch reintroduces PR #4217. Signed-off-by: Tony Allen <tallen@lyft.com>
…voyproxy#4560) This patch reintroduces PR envoyproxy#4217. Signed-off-by: Tony Allen <tallen@lyft.com> Signed-off-by: Aaltan Ahmad <aa@stripe.com>
Description:
This patch introduces the
runtime_fraction
field toRouteMatch
and deprecates theruntime
field. Prior to this field,runtime
only allowed for splitting of traffic amongst clusters with a granularity of 1%, but this new field uses a FractionalPercent structure in the configuration to allow for much smaller amounts to be specified.Using the
runtime_fraction
field will cause theruntime
field to be ignored in a route configuration if they are both specified. If a numerator or denominator is not present in the runtime config for the provided key, or if a key is not provided, the default value provided will be used.Risk Level:
Low
Testing:
Unit tests.
Docs Changes:
Protobuf descriptions.
Release Notes:
n/a
Fixes #4192