Tracking Issue for NameResolution being Experimental.

[carl-mastrangelo]

Specific usages:

• EquivalentAddressGroup
• ManagedChannelBuilder.nameResolverFactory
• NameResolver
• NameResolverRegistry
• ResolvedServerInfo

[b-hoyt]

I'm interested Context-aware name resolution. This doesn't seem obviously possible with the current NameResolver API and usage, but I'm not familiar with the broader set of APIs. Thoughts?

[ejona86]

@b-hoyt I don't know what you mean. Context-aware in what way? Why is it not possible with the current API?

[b-hoyt]

Say for example each client making an RPC call wants to provide hints to name resolution for how the NameResolver might resolve some targetUri that represents an abstract destination "||map_service||". The clients provide these hints, which may vary between requests, as value in the current context.

I can picture how an interceptor, which has access to the Context, may have a reference to the NameResolver in order to supply it with the hints. The NameResolver could do its thing using those hints and updated the associated Listener with the fully ResolvedServerInfos.

But there is no distinction between the ResolvedServerInfos for in-flight-request-A vs. in-flight-request-B, in other words Context scope < ResolvedServerInfos scope

[zhangkun83]

@b-hoyt Name resolution is in the Channel scope, which outlives the Call scope. Allowing individual RPC calls to influence name resolution simply doesn't fit in our architecture.

[ejona86]

@b-hoyt, I'd suggest writing a Channel (not even interrceptor) that creates Channels on-the-fly based on the Context, and re-uses them as appropriate. The other option is to plug into the LB API some, since in some ways GRPCLB does something similar to this.

But I don't see NameResolver supporting this case. As @zhangkun83 mentioned, it is pretty incompatible with the architecture.

[carl-mastrangelo]

API meeting notes:

• Make UNKNOWN_CONFIG package private
• Make ResolutionResults and ResolvedAddress servers field addresses
• Modify parseLoadbalancingPolicyConfig should not suggest implementing equals or hashCode.

[ejona86]

Actually, it was that UNKNOWN_CONFIG would be private, within LoadBalancerProvider.

[ejona86]

#7133 is for removing NameResolver.Factory.