-
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
Add the ability to set the hits_addend for a given rate_limit request via a hardcoded dynamic metadata field #34184
Add the ability to set the hits_addend for a given rate_limit request via a hardcoded dynamic metadata field #34184
Conversation
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
a2d61d8
to
673a527
Compare
The changes to I'm also not sure exactly where the docs should live for this feature. I definitely think that updating the release notes make sense and I can do that, but it could definitely also make sense to add it to the proper docs. |
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
At a high level this seems fine to me. For documentation I would add to the filter specific documentation as well as the release notes. /wait |
Ok, I'll add the documentation, are there any code changes you'd like me to make while I'm at it? |
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
…addend_dynamic_metadata Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
/retest |
format failure /wait |
@jmarantz is there a good way to ensure all of my tools are up to date? When I run formatting it comes up with no diff. Or potentially does the CI job have the diff I need to apply? |
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
// This value can be modified by setting "envoy.ratelimit:hits_addend" in the dynamic metadata | ||
// for a given request. |
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.
In most of cases, we prefer do similar things in the FilterState
rather than dynamic metadata (like various sock options in the filter state and other dynamic configuration from filter state)? Is there any reason prefer the dynamic metadata?
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 based this off of envoy_lb
style decisions which can be made via DynamicMetadata
. I don't have super strong feelings either way, but there are more easier ways to set DynamicMetadata
via other filters so I slightly prefer this method.
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.
envoy.lb
use the metadata because the subset lb construct the match structure from the endpoint metadata.
Then, in this scenario, I think filter state should be preferred for these typed options.
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.
in this case we use dynamic metadata as it allows to feed data in without the source filter being aware that it is for rate limit.
For example, we can use ext-auth server to add the metadata for the rate limit filter.
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.
in this case we use dynamic metadata as it allows to feed data in without the source filter being aware that it is for rate limit. For example, we can use ext-auth server to add the metadata for the rate limit filter.
As far as I know, the ext_authz could only inject the dynamic metadata with namespace envoy.filters.http.ext_authz
?
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 use-case is that we want to dynamically increment the hits_addend
value based on the contents of the body. We have a filter to process the body and then write the value to the dynamic_metadata
. Maybe I'm not understanding the distinction between dynamic_metadata
and filter_state
. Typically I've used dynamic_metadata
to internally pass data between multiple filters, but it seems like there's nuance here I'm missing.
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.
Here are some discussion about the filter state and dynamic metadata #25130
Basically, we prefer to use filter state for non-proto/JSON-like data.
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.
Alright, I plan to use the UInt32Accessor
class. Does that make sense?
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.
@wbpcode does that sound correct?
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.
We have a filter to process the body and then write the value to the dynamic_metadata
Would this also allow forwarding the call to the downstream service and e.g. taking something off the response header for hits_addend
before getting to the rate limiter filter, as described here? envoyproxy/ratelimit#636 (comment)
…oy into hits_addend_dynamic_metadata
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
…addend_dynamic_metadata
@@ -49,6 +49,9 @@ message RateLimitRequest { | |||
|
|||
// Rate limit requests can optionally specify the number of hits a request adds to the matched | |||
// limit. If the value is not set in the message, a request increases the matched limit by 1. | |||
// This value can be overridden by setting filter state value `envoy.ratelimit.hits_addend` | |||
// to the desired number. Invalid number (< 0) or number will be ignored. | |||
|
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.
This is a unnecessary empty line.
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.
Thanks so much for the update and all patience. And so sorry for the delay. This PR is lost in my timeline. (hah, this is not assigned to me. So, the pr reminder doesn't work, but anyway, it's assigned now.)
Almost everything is fine now except two nit comments. And feel free to ping me at slack if you are ready. Then we can merge this PR in time.
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
Responded to all comments, thanks for reviewing and re-assigning. |
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
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. Thanks so much for the long time work. 🌹
@@ -49,6 +49,8 @@ message RateLimitRequest { | |||
|
|||
// Rate limit requests can optionally specify the number of hits a request adds to the matched | |||
// limit. If the value is not set in the message, a request increases the matched limit by 1. | |||
// This value can be overridden by setting filter state value `envoy.ratelimit.hits_addend` |
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.
``envoy.ratelimit.hits_addend``
Please fix the CI, these is a issue that I know. Double backticks should be used.
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
Signed-off-by: code <wbphub@gmail.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.
LGTM. Thanks. Pray for CI 🙏
… via a hardcoded dynamic metadata field (envoyproxy#34184) <!-- !!!ATTENTION!!! If you are fixing *any* crash or *any* potential security issue, *do not* open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) --> Commit Message: Adds the ability to set the hits_addend for a given rate_limit request via a hardcoded dynamic metadata field: envoy.ratelimit:hits_addend. Additional Description: Risk Level: Low Testing: Added unit test. I have also manually tested this using gloo-edge as the control-plane. Docs Changes: Release Notes: Platform Specific Features: N/A [Optional Runtime guard:] N/A [Optional Fixes #Issue] N/A [Optional Fixes commit #PR or SHA] N/A [Optional Deprecated:] N/A [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] N/A --------- Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io> Signed-off-by: code <wbphub@gmail.com> Co-authored-by: code <wbphub@gmail.com> Signed-off-by: Martin Duke <martin.h.duke@gmail.com>
#include "source/extensions/filters/http/ratelimit/ratelimit_headers.h" | ||
|
||
namespace Envoy { | ||
namespace Extensions { | ||
namespace HttpFilters { | ||
namespace RateLimitFilter { | ||
|
||
namespace { | ||
constexpr absl::string_view HitsAddendFilterStateKey = "envoy.ratelimit.hits_addend"; |
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.
@mattklein123 can we make this key configurable per filter?
… via a hardcoded dynamic metadata field (envoyproxy#34184) <!-- !!!ATTENTION!!! If you are fixing *any* crash or *any* potential security issue, *do not* open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) --> Commit Message: Adds the ability to set the hits_addend for a given rate_limit request via a hardcoded dynamic metadata field: envoy.ratelimit:hits_addend. Additional Description: Risk Level: Low Testing: Added unit test. I have also manually tested this using gloo-edge as the control-plane. Docs Changes: Release Notes: Platform Specific Features: N/A [Optional Runtime guard:] N/A [Optional Fixes #Issue] N/A [Optional Fixes commit #PR or SHA] N/A [Optional Deprecated:] N/A [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] N/A --------- Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io> Signed-off-by: code <wbphub@gmail.com> Co-authored-by: code <wbphub@gmail.com> Signed-off-by: asingh-g <abhisinghx@google.com>
Commit Message: Adds the ability to set the hits_addend for a given rate_limit request via a hardcoded dynamic metadata field: envoy.ratelimit:hits_addend.
Additional Description:
Risk Level: Low
Testing: Added unit test. I have also manually tested this using gloo-edge as the control-plane.
Docs Changes:
Release Notes:
Platform Specific Features: N/A
[Optional Runtime guard:] N/A
[Optional Fixes #Issue] N/A
[Optional Fixes commit #PR or SHA] N/A
[Optional Deprecated:] N/A
[Optional API Considerations:] N/A