xDS federation/authorities watch for route broken?

[Gabriel Bordovský]

Hi, 
I am trying to use xDS federation to connect to two separate services each owning its own independent control plane.

I define the authorities in the bootstap file and give each separate "xds_servers" block referencing the coresponding control plane responsible for the services.

I would expect that the top-level xds_servers are sort-of obsolete and not required if I am only using authorities (with specified xds_servers), but since it is mandatory part of the config, I specify server from one of the authorities. 

Each control plane returns different "route_config_name".
The xDS client then then tries to start a watcher for the route
"xds_dependency_manager.cc:339] [XdsDependencyManager 0x7cb61c002cd0] starting watch for route <route-name>".

The issue I am having is, that instead of using an existing connection to control plane, or creating connection to authority related to the <route-name> the top level xds_servers  from bootstrap file is used to create this watcher.

When I debug the calls I get following response:

```
rds {
  config_source {
    ads {
    }
  }
  route_config_name: "<route-name>"
}
http_filters {
  name: "envoy.filters.http.router"
  typed_config {
    type_url: "type.googleapis.com/envoy.extensions.filters.http.router.v3.Router"
  }
}
```

Is there a problem on the control-plane implementation and should the response aside from route name contain an authority name? It is a custom implementation developed in my company, so it is possible there is some error.

But I would expect that this should work as the authority is implicit from the fact that I am already specifying the authority when initializing the gRPC channel and it seems to me that the xDS_client does not propagates the authority information correctly while creating the watcher for route.

Best regards,
Gabriel

[Mark D. Roth]

The XdsClient chooses which control plane to use for each individual resource based on the name of that resource.  It does not just assume that because the LDS resource came from a given authority that all subsequent resources will come from the same authority, because we intentionally want to support cases where one control plane provides some of the resources and then refers to a different control plane for subsequent resources.

In other words, the "<route-name>" in your example needs to be of the form "xdstp://<your_authority>/envoy.config.route.v3.RouteConfiguration/<route_config_id>".  If it's not an xdstp URI, then the client will treat it as an old-style resource name, which will use the top-level list of xDS servers instead of the one in the authority you wanted to use.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/grpc-io/7bb7591c-8c7e-42b9-8910-29c1875115d1n%40googlegroups.com.

--

Mark D. Roth <ro...@google.com>
Software Engineer
Google, Inc.