Skip to content

xds: remove UpstreamTlsContext from XdsChannelBuilder - #6924

Merged
sanjaypujare merged 6 commits into
grpc:masterfrom
sanjaypujare:xds-client-test
Apr 15, 2020
Merged

xds: remove UpstreamTlsContext from XdsChannelBuilder#6924
sanjaypujare merged 6 commits into
grpc:masterfrom
sanjaypujare:xds-client-test

Conversation

@sanjaypujare

Copy link
Copy Markdown
Contributor

No description provided.

@sanjaypujare
sanjaypujare requested a review from creamsoup April 14, 2020 06:43
if (overrideAuthority != null) {
builder = builder.overrideAuthority(overrideAuthority);
}
doAnswer(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this seems very hard / messy to use the SdsNameResolver. Can you do something similar to FakeNameResolver in ManagedChannelImplTest. it is not the best example, but seems simpler than this. also, it is using less resources and provider easier interface to test. Mock should be last option to consider. (e.g. this code can be easily converted to fake impl which will be much shorter and easier to read)

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 find doing mock and doAnswer simpler than how ManagedChannelImplTest.FakeNameResolverFactory.FakeNameResolver does it because you mock/construct the required input inline. But I realize this is subjective and if mock is not the preferred pattern for most people I will switch to it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

no, this is not subjective at all.

mock is definitely anti pattern, in this case it is very easy to not use the mock (even as it is).
But the worse part is the TestSdsNameResolver extends the DnsNameResolver for no reason. The actual use case in test will be the interceptor (Callback) intercepts the onResult and returns a fake result. However, because it is a real DnsNameResolver, it uses thread for no reason, it performs IO for no reason. it even can call Listner#onError unless it is localhost (otherwise it will be environment dependent), and therefore it is pretty much localhost only NameResolver. List can goes on and on. Why we do all of those if we can just make a fake NameResolver, expects a URI and returns a specific value or an error?

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 wanted to do something more general than only for localhost (assuming it could be useful later) so decided to extend DnsNameResolver to be able to add the "mock" attribute for all returned addresses.

I agree the
ManagedChannelImplTest.FakeNameResolverFactory.FakeNameResolver pattern is less intrusive and easier to understand and I will use it. I will be "hardcoding" the localhost -> 127.0.0.1 mapping in my FakeNameResolver. There are cases where the loopback adapter (i.e. 127.0.0.1) is not configured or localhost does not resolve to 127.0.0.1 (but a configured local IP) although very rare - which was another reason I used the DnsNameResolver ("the environment").

public void clientSdsProtocolNegotiatorNewHandler_nullTlsContext() {
ClientSdsProtocolNegotiator pn =
new ClientSdsProtocolNegotiator(/* upstreamTlsContext= */ null);
public void clientSdsProtocolNegotiatorNewHandler_nullTlsContextAttribute() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: should be noTlsContext, null is not allowed.

port = findFreePort();
URI expectedUri = new URI("sdstest://localhost:" + port);
fakeNameResolverFactory = new FakeNameResolverFactory.Builder(expectedUri).build();
channelBuilder =

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this seems worse than what it used to be. this is not even used elsewhere.

.build()
: Attributes.EMPTY;
fakeNameResolverFactory.setServers(
Collections.singletonList(new EquivalentAddressGroup(socketAddress, attrs)));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit/java optional suggestion: using ImmutableList is preferred than Collections.singletonList especially if ImmutableList is already imported.


@Override
public String getDefaultScheme() {
return "fake";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this doesn't match to sdstest

}
}

private static final class FakeNameResolverFactory extends NameResolver.Factory {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

you can remove unused code. private unused code is dead code.

@creamsoup creamsoup left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

@sanjaypujare

Copy link
Copy Markdown
Contributor Author

Thanks @creamsoup !

@sanjaypujare
sanjaypujare merged commit 9618af9 into grpc:master Apr 15, 2020
@sanjaypujare
sanjaypujare deleted the xds-client-test branch April 15, 2020 16:23
dfawley pushed a commit to dfawley/grpc-java that referenced this pull request Jan 15, 2021
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Jun 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants