Xds fallback #11254
Xds fallback #11254
Conversation
larry-safran
force-pushed
the
xds_fallback
branch
from
96cecb2
to
72d9ac9
Compare
| */ | ||
| default void assignResourcesToOwner(XdsResourceType<?> type, Collection<String> resources, | ||
| Object owner) { | ||
| // no-op - useful for test cases where everything is mocked |
There was a problem hiding this comment.
nit:I'm confused by the comment.
There was a problem hiding this comment.
When everything is mocked there is no reason to do anything, so the cases where you want your test to implement ResourceStore you don't need to explicitly define this method that you don't want to use.
| } | ||
|
|
||
| @Override | ||
| public void handleStreamReady(ServerInfo serverInfo) { |
There was a problem hiding this comment.
Is the onReady() callback also supported by stubby xdsTransportFactory? @ejona86
There was a problem hiding this comment.
They have to have something that recognizes that a stream has come ready that can feed into these calls.
larry-safran
force-pushed
the
xds_fallback
branch
from
709026a
to
0c1eef8
Compare
larry-safran
force-pushed
the
xds_fallback
branch
from
af33b25
to
d8f7094
Compare
| if (resources != null) { | ||
|
|
||
| Collection<String> resources = | ||
| resourceStore.getSubscribedResources(serverInfo, resourceType, authority); |
There was a problem hiding this comment.
targetA(channelA) ----> xdsClientA
resource1 (authority1) --> subscriber1
authority1 : [serverInfo1, serverInfo2]
controlPlaneClient ---> serverInfo1
---> serverInfo2
resource2 (authority2) --> subscriber2
authority2 : [serverInfo3, serverInfo4]
controlPlaneClient ---> serverInfo3
---> serverInfo4
resource3 (authority1) --> subscriber3
authority1 : [serverInfo1, serverInfo2]
---> serverInfo1
controlPlaneClient ---> serverInfo2(never happens)
targetA(channelB) ----> xdsClientB
resource1 (authority1) --> subscriber1
...
Each xdsClinet is an instance and has its own the resourceSubscriber map, and separate ads streams for it's resources.
The resources to send request for in this adstream adsStream.sendDiscoveryReuqest should be the resources with the authority the same as in this adsStream.
…d completely disjoint resource names to assuming that any duplicate names would be compatible, particularly cross authority.
|
Fallback is ready for review again. |
| @Nullable | ||
| @Override | ||
| public Collection<String> getSubscribedResources(ServerInfo serverInfo, | ||
| XdsResourceType<? extends ResourceUpdate> type) { | ||
| public Collection<String> getSubscribedResources( |
There was a problem hiding this comment.
Can we simplify this method to something like this?
resources.entrySet().filter( e -> e.serverInfos.contains(serverInfo)).collect...
There was a problem hiding this comment.
I went with the authority approach instead of the ServerInfo because fallback is per authority, so you can have a situation where one authority was complete and another did fallback and requests resources, the first authority's resources would include the fallback server's ServerInfo. We don't want to get an update from the fallback server for the first authority so we don't want to request its resources.
Implementation of https://github.com/grpc/proposal/blob/master/A71-xds-fallback.md in Java