config: enforcing terminal filters are the final filter in their respective chains#7779
Conversation
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
mattklein123
left a comment
There was a problem hiding this comment.
Agreed we should have a dependency language, and we have discussed this before, but also agreed that this is a constant source of mistakes. Do you think we should do something similar with tcp_proxy at the network level?
/wait-any
| request_headers_for_tags: | ||
| - foo | ||
| http_filters: | ||
| - name: envoy.health_check |
There was a problem hiding this comment.
Why is this change needed?
There was a problem hiding this comment.
Not needed - I just wanted the comparable test to have 2 filters in the right order to verify that worked.
Can revert if you'd prefer - obviously we have enough integration tests of multiple filters
There was a problem hiding this comment.
I'm fine either way. I guess I have a mild preference to revert but I don't feel strongly about it.
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
Though in retrospect if we're doing tcp proxy should I also do HCM? |
|
I'm going to go with no, just to avoid sliding down this slippery slope any further. I think if it causes envoy maintainer burden we can always add it later. :-) |
mattklein123
left a comment
There was a problem hiding this comment.
Cool, thanks, agreed let's do this and see how it goes.
|
@alyssawilk please check out my comment here #7767 (comment) before you merge. |
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
zuercher
left a comment
There was a problem hiding this comment.
Thank you!
I took a quick glance over the other network and http filters, and the only other terminal filter that I see is envoy.echo. That said, it's also the least likely to be combined with other filters.
The only other thought I had is whether it's worth it document these or if just preventing the incorrect usage is enough.
|
Oh actually, should we require a terminal filter at the end of a filter chain? |
+1 this SGTM |
|
+1 on terminal filter, though that may make this a breaking change for folks. I'll definitely add this to the version history. I don't think it merits envoy-announce but please chime in if you think it does. |
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks this is great. 1 small question and also needs a master merge.
/wait
| processFilter(filters[i], i, "http", filter_factories_); | ||
| bool is_terminal = false; | ||
| processFilter(filters[i], i, "http", filter_factories_, is_terminal); | ||
| if (is_terminal && i != filters.size() - 1) { |
There was a problem hiding this comment.
This logic is repeated in multiple places (and I think not fully repeated in the upgrade path below). Can we put into a helper function potentially and use that everywhere?
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks this is really awesome. @zuercher any further comments?
|
Argh. |
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
ok, undid the "and the last filter must be terminal" for network with some TODOs. I'll land an update to echo2, then reinstate what I had last commit (unless there's a better way to handle the various repos) |
mattklein123
left a comment
There was a problem hiding this comment.
LGTM post security release
follow up to envoyproxy/envoy#7779 Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
An (no longer annoyingly one-off) solution to the common problem folks run into with Envoy configs where they add their filters behind the router filter and don't get why things aren't working. Ditto for HCM, tcp_proxy etc for L4
Risk Level: Low (except for folks with broken config)
Testing: new UT
Docs Changes: n/a
Release Notes: n/a
Fixes #7767