grpc-go
grpc-go copied to clipboard
grpc
xds: fix cluster_resolver LB policy behavior upon receipt of NACKed EDS resource
Let's say the cluster_resolver LB policy receives two discovery mechanisms as part of its configuration: a higher priority EDS and a lower priority LOGICAL_DNS cluster. The cluster_resolver LB policy creates child policy configs only after both discovery mechanisms are resolved.
Let's specifically consider the case where the first EDS response for the higher priority EDS cluster is NACKed by the xDS client. This is handled by the edsDiscoveryMechanism here: https://github.com/grpc/grpc-go/blob/2cd95c7514a3d02aa2d98591c013885cb44fbdeb/xds/internal/balancer/clusterresolver/resource_resolver_eds.go#L72
The error is propagated to the cluster_resolver LB policy by pushing it onto a channel here: https://github.com/grpc/grpc-go/blob/2cd95c7514a3d02aa2d98591c013885cb44fbdeb/xds/internal/balancer/clusterresolver/resource_resolver.go#L283
At this point, since the cluster_resolver has not created a child policy (because it has not received valid responses from both discovery mechanisms), it will report TransientFailure to its parent here: https://github.com/grpc/grpc-go/blob/2cd95c7514a3d02aa2d98591c013885cb44fbdeb/xds/internal/balancer/clusterresolver/clusterresolver.go#L256
Instead the cluster_resolver should treat this error from the xDS client as though it received an EDS response with a single priority and no localities. This will allow it to create the priority child (once it receives a response from the DNS mechanism as well), and will allow it to fail over to it.
Also, the cluster_resolver LB policy should do the same thing if the EDS watcher returns a resource-does-not-exist error. The only difference between a resource NACK error and a resource-does-not-exist error is that the former ignores the error if there was a previous result, whereas the latter does not.
Actually, this one is better off waiting on another item that @easwars is planning to do.
