go-control-plane: Multiple listeners is not working with Golang XDS Client

I was trying to use multiple listens with Go lang XDS client. According to the go documentation, gRPC client must be tolerant of servers that may ignore the resource name in the request. I wasn’t able to make that work and while debugging, I found that the code is expecting clients to send all resources names in the request. The relevant code for that check is https://github.com/envoyproxy/go-control-plane/blob/9821e2beedf61fd8fc3b8e27589f2d5e210652c2/pkg/cache/v2/simple.go#L167

According to the Go doc, the resource name is the server name hence it is not possible to send all resources in the request.

From Go doc -

The gRPC client will typically start by sending an LDS request for a Listener resource whose name matches the server name from the target URI used to create the gRPC channel (including port suffix if present).

I modified the code as below and it worked as expected. I am open to submit a PR, let me know.

func superset(names map[string]bool, resources map[string]types.Resource) error {
	for resourceName := range resources {
		if _, exists := names[resourceName]; exists {
			return nil
		}
	}
	return fmt.Error("resource is not listed)
}

About this issue

Original URL
State: open
Created 4 years ago
Comments: 17 (3 by maintainers)

Most upvoted comments

Using gRPC does not require using the incremental xDS protocol variants. It’s just using a non-wildcard request for LDS and CDS, as per the xDS spec:

https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#how-the-client-specifies-what-resources-to-return

The logic needed in the xDS server is not hard to implement. Basically, if the initial request on the xDS stream for a given resource type does not set the resource_names field, then it’s a wildcard request; otherwise, the server should return the specific set of reources that the client requested. The only tricky part is that wildcard requests can only be used on the first request on the stream for a given resource type; if the client initially sends a non-wildcard request and then later sends a request with no resource_names field, that means that the client is unsubscribing from the last resource.

That having been said, I will also point out that even if a given xDS server supports only wildcard mode with LDS, it should work fine with a gRPC client, as long as one of the returned Listener resources has the name that the client requested. So I think all that you really need here is to make sure that one of the Listener resources returned by the xDS server has the name that the client is interested in.

@dfawley and @menghanl can comment on the gRPC-Go xDS client implementation.

markdroth on Sep 30, 2020

Apparently, this fxies the issue. It worked for me, at least (grpc 1.38 + go-control-plane 0.9.9) https://github.com/grpc/grpc-go/issues/5131#issuecomment-1022434793

grobza on Apr 13, 2022

Delta xDS is not yet implemented here, so CDS/LDS are state-of-the-world at the moment. We haven’t validated that gRPC can actually work with this server implementation.

kyessenov on Sep 15, 2020

It should handle 0 resource names here https://github.com/envoyproxy/go-control-plane/blob/9821e2beedf61fd8fc3b8e27589f2d5e210652c2/pkg/cache/v2/simple.go#L240. LDS and CDS are always requested in bulk. I think we exercise that in “xds” integration tests.

kyessenov on Aug 28, 2020