-
Notifications
You must be signed in to change notification settings - Fork 5.1k
config: enforcing terminal filters are the final filter in their respective chains #7779
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
Conversation
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
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.
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
@@ -166,6 +196,9 @@ stat_prefix: router | |||
request_headers_for_tags: | |||
- foo | |||
http_filters: | |||
- name: envoy.health_check |
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.
Why is this change needed?
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. :-) |
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.
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>
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.
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>
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
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 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) |
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 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