-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
extension: add test case #13915
extension: add test case #13915
Conversation
Signed-off-by: Yuchen Dai <[email protected]>
TODO: http request verifier, host data Signed-off-by: Yuchen Dai <[email protected]>
Signed-off-by: Yuchen Dai <[email protected]>
Signed-off-by: Yuchen Dai <[email protected]>
Signed-off-by: Yuchen Dai <[email protected]>
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 for the test, I left a few comments to get this started
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 for the review! I will fix and update the PR later today
Signed-off-by: Yuchen Dai <[email protected]>
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.
@snowp I am seeing checkformat failure on my new "test/integration/upstream/BUILD"
The auto fix is to add envoy_package(), but that fix actually fail the entire build. Any suggestion?
Signed-off-by: Yuchen Dai <[email protected]>
The root cause: envoy_build_fixer.py likes either envoy_package or envoy_extension_package(sole in source/extensions). Now that the newly add extension is only used by integration test, I choose to declare in in |
Signed-off-by: Yuchen Dai <[email protected]>
Seems like CI is broken, can you fix and then I'll take a look? /wait |
Signed-off-by: Yuchen Dai <[email protected]>
@snowp Thank you for the reminder |
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 looks better, just a few comments.
Would appreciate @alyssawilk's thoughts as well, in particular on the general usefulness of this test: part of me feels like this is pretty guaranteed to continue to work no matter what happens in the router and elsewhere.
Envoy::Http::HeaderMapImpl::copyFrom(*dup, headers); | ||
dup->setCopy(Envoy::Http::LowerCaseString("X-foo"), "foo-common"); | ||
addHeader(*dup, "X-cluster-foo", host_->cluster().metadata(), "foo", "bar"); | ||
if (host_->metadata() != nullptr) { | ||
addHeader(*dup, "X-host-foo", *host_->metadata(), "foo", "bar"); | ||
} |
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.
If you're only trying to verify that you can modify headers in the upstream extension why the complexity here? Why not just a single header?
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 idea is that I don't want to add test case because
"Envoy can do this in this current implementation" but
"This is real world requirement"
Also this can acts an example for user who want to rewrite header base on per upstream attribute like #13897
Does it make sense?
// This test case should be rewritten once upstream http | ||
// filters(https://github.com/envoyproxy/envoy/issues/10455) is landed. |
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.
If this is something that we want to support and validate via a test it seems like we should keep this test for perpetuity - just because you'd rewrite your extension to be a HTTP filter instead it doesn't mean everyone else would.
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.
As I explained in the other comment: This is an unfortunate constraint。
I am happy to refactor my upstream extension if upstream HTTP filter could achieve the goal providing alternative api.
So consider this as soft requirement when you are working on it
gentle ping @alyssawilk |
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 agree that it feels clear that this functionality will stick around. I will say given how often Envoy APIs shift around it isn't terrible to have a canonical example, so that if API / factory changes happen there's also a canonical transformation PR, if that makes sense? Basically don't know if it's necessary but I'm not averse.
Either way, sorry for the lag, and here's some thoughts on how we can limit code duplication and tighten it up a bit :-)
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
Signed-off-by: Yuchen Dai <[email protected]>
Signed-off-by: Yuchen Dai <[email protected]>
Signed-off-by: Yuchen Dai <[email protected]>
Signed-off-by: Yuchen Dai <[email protected]>
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 @alyssawilk
Now the extension is a single header file. It is much cleaner for the test.
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
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, much cleaner, thanks!
Just two more comments and you're good to go.
void resetStream() override { sub_upstream_.resetStream(); } | ||
|
||
private: | ||
Extensions::Upstreams::Http::Http::HttpUpstream sub_upstream_; |
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.
Oh, I was thinking if you inherit from the HTTP upstream rather than wrap it, you can remove all the wrapper functions (which simply call sub_upstream_.function). WDYT?
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.
Updated. The new shape is less error prone for this task. Thanks!
test/integration/cluster_upstream_extension_integration_test.cc
Outdated
Show resolved
Hide resolved
Signed-off-by: Yuchen Dai <[email protected]>
…3915) Add extra test case to guard that cluster upstream extension support header rewrite. Signed-off-by: Yuchen Dai <[email protected]> Signed-off-by: Qin Qin <[email protected]>
Commit Message:
Add extra test case to guard that cluster upstream extension support header rewrite.
Additional Description:
Risk Level: LOW
Testing: Integration test
Docs Changes:
Release Notes:
Platform Specific Features: