Breaking Change: xds `Return no matching virtual host found` error

[ankittk]

What version of gRPC are you using?

v1.62.1

What version of Go are you using (go version)?

go1.20

What operating system (Linux, Windows, …) and version?

Linux/Mac

What did you do?

I simply updated my grpc version to the latest, as I saw in the release, this PR #6997
caused this.

What did you expect to see?

This is a breaking change, all services will start to fail if you try to find your service discovery path. There should be some way to fix this instead of returning an error.

What did you see instead?

rpc error: code = Unavailable desc = last resolver error: no matching virtual host found for "exampleService"

[arvindbr8]

Hi @ankittk -- this is weird since we didnt expect any existing users to be impacted with the bug fix in #6997. Essentially this bug only effects the user is the LDS resource name differs from the target used for Dial

This is a breaking change, all services will start to fail if you try to find your service discovery path.

Its not evident what you mean here. Are you seeing a regression in grpc-go v1.62.1?

If so, could you give us more clarity by:

1. What is the flavor of the management server being used here?
2. Could you let us know the dial target used in your case
3. Could you turn up the debug level on the client and provide us a dump of the ADS requests/responses (we can check what the LDS resource name sent here is)

If not, could you explain what "find your service discover path" means here?

[atollena]

grpc-go now uses the target string instead of the xdstp URL when looking into the list of vhosts. So if the control plane sets vhost to something like xdstp://<authority>/<resource_type>/<id> and set client_default_listener_resource_name_template to replace the grpc target when looking up LDS resources, it worked fine until #6997, but breaks after that.

We ran into this with our own custom xDS server base on a fork of go-control-plane. If this had been used in production, it would have broken existing services. It may be possible to set multiple virtual hosts, one with the old and one with the new format, from the control plane.

For us that was not a problem in practice because our control plane is still in development. @ankittk 's problem may be a different one.

[arvindbr8]

Before #6997 gRPC-go used to lookup vHost using the LDS resource name. This was broken when there was a client_default_listener_resource_name_template or client_listener_resource_name_template used in the bootstrap config.

The bug fix in #6997 was to align with the spec in gRFC A47: xDS Federation, which says:

... the authority used for the data plane connections (which is also used to select the VirtualHost within the xDS RouteConfiguration) will continue to be the last path component of the xds URI used to create the gRPC channel (i.e., the part following the last / character, or the entire path if the path contains no / character).

Yes I agree this is a behavior change and would be a breaking change for some users, but this was a bug in the implementation before and needs to align with the gRFC.

---

@atollena - xRFC TP1 talks about the naming schema for xDS resources. I think xdstp style name does not apply to vHosts field in RDS (iiuc, only used when VHDS is used). The vHosts field in RDS is not a xDS resource but the authority used to make the data plane connection.

The right approach for the xDS server would be to send only with the old format, or use wildcard for vHosts (which is the case with TrafficDirector).

[atollena]

To be clear from my perspective this change is OK, the fix should be on the control plane side. But it looks like the original poster ran into the same problem. I would suggest closing this issue as answered, unless @ankittk's doesn't have the opportunity to fix it on the control plane side (by using wildcard, for example).

[github-actions]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[ankittk]

You are right, we have fixed that on client side.
Thank you