-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
policy: Add support for HTTPRetryFilter #11117
Conversation
d8c7cff
to
7d2419d
Compare
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 looking good to me!
fn convert_linkerd_filter(filter: api::httproute::HttpRouteFilter) -> Result<Filter> { | ||
fn convert_linkerd_filter( | ||
filter: api::httproute::HttpRouteFilter, | ||
retry_policy: &mut Option<LocalObjectReference>, |
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.
curious why we return the retry policy by passing in a mut pointer instead of doing something like changing the return type into a tuple or struct?
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.
returning a tuple would also work. if we returned a tuple, the code for checking if there was already a retry policy would need to be at the call site instead of in this function. i don't think it's a huge difference either way.
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.
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.
Seems fine. If we wanted to be super clean about this we could use partition
to split the rule.filters
into two iterators: one for filters that will get turned into retry policy and one for filters that get turned into filters in the proxy api. But I'm splitting the bikeshed's hairs at this point.
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.
hmm, yeah, partition
is a kind of nice idea, i might mess with this some more. but, the current solution seems fine if you're okay with it.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
In order to support retries for HTTPRoute traffic, we introduce a new
HTTPRetryFilter CRD to be used for configuring retry policy at the level
of individual rules in an HTTPRoute. An HTTPRoute rule can reference a
HTTPRetryFilter using the
ExtensionRef
filter type. This branchimplements the required behavior in the policy controller to watch
HTTPRetryFilters and associate them with HTTPRoute rules that reference
them. The policy controller now populates the additional fields for
retry policies added to the proxy API in linkerd/linkerd2-proxy-api#256.
In order to support the new HTTPRetryFilter, we must also modify the
policy.linkerd.io
version of the HTTPRoute resource to support the useof
ExtensionRef
filters, so this branch makes that change as well.Note that this branch should not be merged until:
Depends on #11106