Skip to content
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

Merged
merged 15 commits into from
Sep 19, 2018

Conversation

tonya11en
Copy link
Member

Description:
This patch introduces the runtime_fraction field to RouteMatch and deprecates the runtime 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 the runtime 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

@@ -689,6 +689,27 @@ const std::string Json::Schema::ROUTE_ENTRY_CONFIGURATION_SCHEMA(R"EOF(
"required" : ["key", "default"],
"additionalProperties" : false
},
"runtime_fraction" : {
Copy link
Contributor

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

@danielhochman danielhochman self-assigned this Aug 21, 2018
Signed-off-by: Tony Allen <tallen@lyft.com>
@tonya11en
Copy link
Member Author

Just FYI- looks like my api check has fallen victim to #4218. Everything else is in good working order though.


// Runtime derived FractionalPercent with defaults for when the numerator or denominator is not
// specified via a runtime key.
message RuntimeFractionalPercent {
Copy link
Contributor

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.

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();
Copy link
Contributor

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

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;
Copy link
Contributor

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.

@danielhochman
Copy link
Contributor

looking good. minor comments.

Tony Allen added 2 commits August 23, 2018 11:31
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
danielhochman
danielhochman previously approved these changes Aug 24, 2018
@tonya11en
Copy link
Member Author

@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.

Copy link
Member

@zuercher zuercher left a 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 Show resolved Hide resolved
FractionalPercent::DenominatorType denominator_type;
if (!FractionalPercent::DenominatorType_Parse(denominator_data, &denominator_type)) {
denominator_type = route_match.runtime_fraction().default_value().denominator();
}
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

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?

Copy link
Member

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.

@htuch htuch assigned htuch and unassigned ggreenway Aug 30, 2018
Tony Allen added 2 commits August 30, 2018 18:36
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
api/envoy/api/v2/route/route.proto Show resolved Hide resolved
// 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
Copy link
Member

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.

Tony Allen added 2 commits September 4, 2018 13:48
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
Copy link
Member

@htuch htuch left a 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).


// Runtime derived FractionalPercent with defaults for when the numerator or denominator is not
// specified via a runtime key.
message RuntimeFractionalPercent {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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).

api/envoy/type/runtime_percent.proto Outdated Show resolved Hide resolved
Tony Allen added 2 commits September 5, 2018 11:01
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks!

@htuch
Copy link
Member

htuch commented Sep 6, 2018

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...

@tonya11en
Copy link
Member Author

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.

@zuercher zuercher added the no stalebot Disables stalebot from closing an issue label Sep 10, 2018
@tonya11en
Copy link
Member Author

@htuch are you able to re-run the ci/circleci: mac test now that #4413 is merged? I don't have privileges to do so.

@htuch
Copy link
Member

htuch commented Sep 12, 2018

@tonya11en you'll need to merge master to pick up that change; if you do that and push the CI will rerun.

Tony Allen added 6 commits September 12, 2018 14:07
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Tony Allen <tallen@lyft.com>
@mattklein123 mattklein123 merged commit 75e54d0 into envoyproxy:master Sep 19, 2018
@tonya11en tonya11en deleted the fractional_percent branch September 19, 2018 21:29
@lizan lizan mentioned this pull request Sep 20, 2018
htuch added a commit to htuch/envoy that referenced this pull request Sep 20, 2018
…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>
htuch added a commit that referenced this pull request Sep 20, 2018
…ting (#4217)" (#4482)

This reverts commit 75e54d0.

This was breaking Mac CI due to known PGV CLI limits.

Signed-off-by: Harvey Tuch <htuch@google.com>
@htuch
Copy link
Member

htuch commented Sep 28, 2018

@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.

tonya11en pushed a commit to tonya11en/envoy that referenced this pull request Sep 28, 2018
htuch pushed a commit that referenced this pull request Sep 30, 2018
)

This patch reintroduces PR #4217.

Signed-off-by: Tony Allen <tallen@lyft.com>
aa-stripe pushed a commit to aa-stripe/envoy that referenced this pull request Oct 11, 2018
…voyproxy#4560)

This patch reintroduces PR envoyproxy#4217.

Signed-off-by: Tony Allen <tallen@lyft.com>
Signed-off-by: Aaltan Ahmad <aa@stripe.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no stalebot Disables stalebot from closing an issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants