Skip to content
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

Merged
merged 14 commits into from
Nov 23, 2020
Merged

extension: add test case #13915

merged 14 commits into from
Nov 23, 2020

Conversation

lambdai
Copy link
Contributor

@lambdai lambdai commented Nov 5, 2020

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:

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]>
Copy link
Contributor

@snowp snowp left a 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

Copy link
Contributor Author

@lambdai lambdai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snowp

Thanks for the review! I will fix and update the PR later today

Signed-off-by: Yuchen Dai <[email protected]>
Copy link
Contributor Author

@lambdai lambdai left a 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?

@lambdai
Copy link
Contributor Author

lambdai commented Nov 10, 2020

@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?

The root cause: envoy_build_fixer.py likes either envoy_package or envoy_extension_package(sole in source/extensions).
The above make sense.

Now that the newly add extension is only used by integration test, I choose to declare in in envoy_package.

@snowp
Copy link
Contributor

snowp commented Nov 10, 2020

Seems like CI is broken, can you fix and then I'll take a look?

/wait

@lambdai
Copy link
Contributor Author

lambdai commented Nov 10, 2020

@snowp Thank you for the reminder
Yeah, I reproduce locally when I merged the latest master. Look like linux_x64 release is passing and I expect the rest will pass soon

Copy link
Contributor

@snowp snowp left a 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.

Comment on lines 89 to 94
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");
}
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Comment on lines 62 to 63
// This test case should be rewritten once upstream http
// filters(https://github.com/envoyproxy/envoy/issues/10455) is landed.
Copy link
Contributor

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.

Copy link
Contributor Author

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

@lambdai
Copy link
Contributor Author

lambdai commented Nov 12, 2020

gentle ping @alyssawilk

Copy link
Contributor

@alyssawilk alyssawilk left a 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 :-)

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]>
Copy link
Contributor Author

@lambdai lambdai left a 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.

Copy link
Contributor

@alyssawilk alyssawilk left a 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_;
Copy link
Contributor

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?

Copy link
Contributor Author

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!

@lambdai lambdai requested a review from snowp November 18, 2020 18:07
@snowp snowp merged commit 4f5b40c into envoyproxy:master Nov 23, 2020
qqustc pushed a commit to qqustc/envoy that referenced this pull request Nov 24, 2020
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants