A95: xDS Endpoint Fallback

[markdroth]

No description provided.

[ejona86]

How will this new data be encoded coming out of XdsDependencyManager in A74? We'll need to update XdsEndpointResource to support a reference to LbEndpointCollection, but do we

1. have XdsDependencyManager have a list of the localities with their own LbEndpointCollectionResource (closer to how we handle XdsRouteConfigResource) or
2. rewrite the XdsEndpointResource to remove the references and inline the endpoint information as if LEDS wasn't used?

[markdroth]

There are two different API layers here:

1. The XdsConfig representation generated by XdsDependencyManager and exposed to the resolver and LB policy code.
2. The individual resource type implementations exposed from XdsClient to XdsDependencyManager.

I think that for (1), the representation wouldn't change, since that representation already combines all resources into a single data structure, and that data structure is essentially structured in terms of how we need to use the data in the LB policy tree, independently of how it was represented in xDS resources.

For (2), there needs to be a separate object for each individual xDS resource, since each resource type that we plug into XdsClient needs to produce some type for the parsed resource. But since the LbEndpointCollection can either be inlined in EDS or obtained from a separate LEDS resource, I expect that we'll handle this the same way that we do for the RouteConfiguration, which can either be inlined in LDS or obtained from a separate RDS resource. In C-core, we handle this by having a field in the parsed LDS resource that either specifies the RDS resource name or inlines the parsed RouteConfiguration. So I expect that what we'll do here is to add a new LEDS resource, and then change the existing parsed EDS representation to specify either the name of the LEDS resource or the parsed LbEndpointCollection itself.

Note that the actual parsing logic for the LbEndpointCollection is the same, regardless of whether it's inlined in EDS or sent in a separate LEDS resource. So we should be able to just refactor the current EDS parsing code; we shouldn't need to duplicate it. Today, when the RouteConfiguration is inlined into the LDS resource, the LDS resource parser essentially calls out to the RDS resource parser. I expect that we'll do the same here, where the EDS parser will call out to the LEDS parser.

[ejona86]

(2) seems pretty clear to me; we've done that before, including code sharing.

For (1), A74 has:

    struct EndpointConfig {
      XdsEndpointResource endpoints;
      std::string resolution_note;
    };

Are you saying XdsEndpointResource is a different object than produced by XdsClient? That's news to me. And that's surprising, as then there'd be no need for route_config, as that could be inlined into XdsListenerResource:

struct XdsConfig {
  // Listener resource.
  XdsListenerResource listener;
  // RouteConfig resource.  Will be populated even if RouteConfig is
  // inlined into the Listener resource.
  XdsRouteConfigResource route_config;

Right now I thought the resources presented in XdsConfig are identical to what was received. I agree we could change them, but we already had an opportunity to rewrite one and we didn't take it. So I feel like we need to spell out what's expected here, since this is also the sort of thing you want everyone doing the same way.

[markdroth]

Sorry, I misunderstood your question. You're right, we need to change the XdsConfig representation.

I've added some text to spell this out.