Skip to content

xds: Add LEDS list collection support (A95) - #13055

Draft
shivaspeaks wants to merge 2 commits into
grpc:masterfrom
shivaspeaks:leds-2
Draft

xds: Add LEDS list collection support (A95)#13055
shivaspeaks wants to merge 2 commits into
grpc:masterfrom
shivaspeaks:leds-2

Conversation

@shivaspeaks

@shivaspeaks shivaspeaks commented Sep 13, 2026

Copy link
Copy Markdown
Member

Implements part 2 of gRFC A95: support for fetching a locality's endpoints as a separate LbEndpointCollection (LEDS) list collection resource

@shivaspeaks

Copy link
Copy Markdown
Member Author

Note for Reviewer

1. Map Values use StatusOr: The gRFC struct defines std::map<std::string, XdsLbEndpointCollectionResource>, but this PR models it as ImmutableMap<String, StatusOr<LbEndpointCollectionUpdate>>. This matches how XdsConfig handles all other resources (e.g., getClusters()). It ensures that one bad collection gracefully degrades only a single locality, rather than failing the entire cluster.

2. No separate resolution_note field: The gRFC specifies a resolution_note string, but today grpc-java folds resolution errors into the existing StatusOr<EdsUpdate> payload.

3. Missing or Invalid Collections ⇒ Locality Unreachable: The gRFC only explicitly defines that empty entries make a locality unreachable. I extended this behavior to missing or invalid collections. The observable state is identical, and it prevents a single missing LEDS resource from failing the cluster. (If all localities fail this way, CdsLoadBalancer2 still correctly reports "No usable endpoint from cluster").

4. Empty leds_collection_name: Not explicitly rejected during parsing; instead, it gracefully degrades into a never-arriving resource, rendering the locality unreachable.

5. NACK Blast Radius: A NACK'd collection fails only that specific collection. This aligns with standard XdsResourceType behavior, keeping the blast radius strictly scoped.

6. Resource Keys: shouldRetrieveResourceKeysForArgs() is set to true, mirroring EDS rather than RDS/LDS.

7. Updating EndpointConfig.equals() and hashCode() to include the new map is not just cosmetic. Without this, maybePublishConfig() would suppress updates that compare equal to the last one. A LEDS-only endpoint change (the entire point of this feature) would be silently swallowed because the underlying EDS resource wouldn't have changed. I added the verify_ledsCollectionUpdate_republishesConfig test specifically to pin this behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant