Skip to content

StreamInfo: Add downstreamDirectRemoteAddress#5064

Merged
htuch merged 12 commits intoenvoyproxy:masterfrom
aunu53:direct
Dec 14, 2018
Merged

StreamInfo: Add downstreamDirectRemoteAddress#5064
htuch merged 12 commits intoenvoyproxy:masterfrom
aunu53:direct

Conversation

@aunu53
Copy link
Copy Markdown
Contributor

@aunu53 aunu53 commented Nov 16, 2018

Signed-off-by: Auni Ahsan auni@google.com

Description: The downstreamRemoteAddress field is modified when the remote address is inferred from proxy information or headers. This new field guarantees to hold the directly connected host's physical address.
Risk Level: Low
Testing: Searched around for references to downstreamRemoteAddress() and filled in similar tests/mocks.

Fixes #4996.

Signed-off-by: Auni Ahsan <auni@google.com>
@aunu53 aunu53 changed the title Add downstreamDirectlyConnectedAddress to StreamInfo StreamInfo: Add downstreamDirectlyConnectedAddress Nov 16, 2018
@mattklein123
Copy link
Copy Markdown
Member

@dnoe PTAL

@aunu53
Copy link
Copy Markdown
Contributor Author

aunu53 commented Nov 19, 2018

what is PTAL?

@stale
Copy link
Copy Markdown

stale bot commented Nov 26, 2018

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Nov 26, 2018
Copy link
Copy Markdown
Member

@venilnoronha venilnoronha left a comment

Choose a reason for hiding this comment

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

Looks good overall. Can you add a test to verify that the downstreamDirectlyConnectedAddress does return the actual physical address even when the downstreamRemoteAddress is mutated via proto or headers? Also, it'd be good to note this new API in the release notes (version_history.rst file).

@stale stale bot removed stale stalebot believes this issue/PR has not been touched recently labels Nov 28, 2018
@dnoe
Copy link
Copy Markdown
Contributor

dnoe commented Nov 29, 2018

I'm going to have to punt this off on someone else since I have a critical issue on my plate this week. Thanks for taking an initial look @venilnoronha - let me know when it is ready from your standpoint and I will move it forward.

@venilnoronha
Copy link
Copy Markdown
Member

@dnoe will do.

@venilnoronha
Copy link
Copy Markdown
Member

/assign @venilnoronha

Signed-off-by: Auni Ahsan <auni@google.com>
@stale
Copy link
Copy Markdown

stale bot commented Dec 6, 2018

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Dec 6, 2018
@venilnoronha
Copy link
Copy Markdown
Member

Not stale.

@stale stale bot removed the stale stalebot believes this issue/PR has not been touched recently label Dec 6, 2018
@aunu53
Copy link
Copy Markdown
Contributor Author

aunu53 commented Dec 9, 2018

Sorry for the delay, was out sick last week. There's no test ascertaining the changing state for downstreamRemoteAddress(), so I tacked on w xff to a conn manager impl test.

@aunu53 aunu53 force-pushed the direct branch 2 times, most recently from 8acb682 to 726ffb5 Compare December 9, 2018 16:26
@aunu53 aunu53 requested review from htuch and lizan as code owners December 9, 2018 16:26
@htuch
Copy link
Copy Markdown
Member

htuch commented Dec 9, 2018

@auni53 there are build issues here under ASAN and other CI tests, can you take a look?

}
stream_info_.setDownstreamLocalAddress(
connection_manager_.read_callbacks_->connection().localAddress());
stream_info_.setDownstreamDirectlyConnectedAddress(
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think I would prefer downstreamDirectRemoteAddress() for consistency with existing naming, or something like that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'm fine with that, changing

constexpr char local_address[] = "0.0.0.0";
constexpr char xff_address[] = "1.2.3.4";

// stream_info.directRemoteAddress() will populate from xff
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

directRemoteAddress? How does this populate from XFF?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

whoops, made a typo. cleaned up the comment, is this fine?

}

TEST_F(HttpConnectionManagerImplTest, TestAccessLog) {
constexpr char local_address[] = "0.0.0.0";
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ideally we also have a more specific unit test on ConnectionManagerImpl::ActiveStream::ActiveStream, i.e. HCM, that shows this behavior. If there's a reasonable way to add this without too many gymnastics, that could be great.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Looking into this, but I'm trying to find out whether ActiveStream is usually tested in isolation without an http conn manager. In TestAccessLog (l 970) the ActiveStream is already directly instantiated as decoder and decodeHeaders is called on it.

Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
@aunu53 aunu53 changed the title StreamInfo: Add downstreamDirectlyConnectedAddress StreamInfo: Add downstreamDirectRemoteAddress Dec 11, 2018
Signed-off-by: Auni Ahsan <auni@google.com>
@aunu53
Copy link
Copy Markdown
Contributor Author

aunu53 commented Dec 11, 2018

Kinda bizarre...the build failures are actually just clang-tidy failures, but they only throw on asan/tsan/mac runs. (Still wish there was an easier way to validate these errors than waiting a long time.)

Signed-off-by: Auni Ahsan <auni@google.com>
Copy link
Copy Markdown
Member

@venilnoronha venilnoronha 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 cleaning up the PR.

Signed-off-by: Auni Ahsan <auni@google.com>
@aunu53
Copy link
Copy Markdown
Contributor Author

aunu53 commented Dec 11, 2018

Oopsy, thanks for catching that. Fixed that error + the nit.

clang-tidy errors are outstanding, but it won't tell me what's wrong so running it locally.

@repokitteh-read-only

This comment has been minimized.

Copy link
Copy Markdown
Member

@venilnoronha venilnoronha left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks!

@venilnoronha
Copy link
Copy Markdown
Member

@auni53 you can ignore the clang_tidy error. It's just a timeout.

ci/build_setup.sh: line 115:   199 Hangup                  ./run_clang_tidy.sh
Too long with no output (exceeded 10m0s)

@htuch over to you for another pass.

Copy link
Copy Markdown
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Great, thanks!

@aunu53
Copy link
Copy Markdown
Contributor Author

aunu53 commented Dec 12, 2018

@lizan could you take a look at this? The clang_tidy tests on circleCI time out, and my local run isn't showing me anything useful.

Local run details: I ran ./ci/run_envoy_docker.sh ci/do_ci.sh bazel.clang_tidy; it compiled the DB and had a bunch of "x warnings generated" messages without any errors. The beginning of the run included this error/warning repeated a few times:

WARNING: Duplicate rc file: /source/tools/bazel.rc is read multiple times, most recently imported from /source/ci/.bazelrc
WARNING: Processed legacy workspace file /source/ci/tools/bazel.rc. This file will not be processed in the next release of Bazel. Please read https://github.com/bazelbuild/bazel/issues/6319 for further information, including how to upgrade.

@lizan
Copy link
Copy Markdown
Member

lizan commented Dec 13, 2018

@auni53 can you merge master to see how it goes? I add an echo for clang-tidy to identify the problem.

Signed-off-by: Auni Ahsan <auni@google.com>
@aunu53
Copy link
Copy Markdown
Contributor Author

aunu53 commented Dec 13, 2018

doneeee

@repokitteh-read-only
Copy link
Copy Markdown

🙀 Error while processing event:

evaluation error
error: context deadline exceeded
🐱

Caused by: a #5064 (comment) was created by @auni53.

see: more, trace.

@htuch
Copy link
Copy Markdown
Member

htuch commented Dec 14, 2018

@lizan still not seeing any useful debug here. Do we just want to force merge this PR or is this a useful reproducer to keep investigating with?

@lizan
Copy link
Copy Markdown
Member

lizan commented Dec 14, 2018

@htuch I opened #5296 to debug CI, if you want to merge this PR sooner, then I think it is OK to force merge.

@htuch
Copy link
Copy Markdown
Member

htuch commented Dec 14, 2018

@lizan ok, will force merge when a reasonable number of these presubmits pass.

@venilnoronha
Copy link
Copy Markdown
Member

/retest

@repokitteh-read-only
Copy link
Copy Markdown

🔨 rebuilding ci/circleci: clang_tidy (failed build)
🔨 rebuilding ci/circleci: asan (failed build)

🐱

Caused by: a #5064 (comment) was created by @venilnoronha.

see: more, trace.

@htuch htuch merged commit 13d6396 into envoyproxy:master Dec 14, 2018
@aunu53 aunu53 deleted the direct branch December 14, 2018 13:22
fredlas pushed a commit to fredlas/envoy that referenced this pull request Mar 5, 2019
The downstreamRemoteAddress field is modified when the remote address is inferred from proxy information or headers. This new field guarantees to hold the directly connected host's physical address.

Risk Level: Low
Testing: Searched around for references to downstreamRemoteAddress() and filled in similar tests/mocks.

Fixes envoyproxy#4996.

Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Fred Douglas <fredlas@google.com>
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.

6 participants