Skip to content

api: move ATTR_ADDRESS_NAME to EquivalentAddressGroup - #13072

Merged
shivaspeaks merged 1 commit into
grpc:masterfrom
shivaspeaks:move-ATTR_ADDRESS_NAME-to-api
Sep 24, 2026
Merged

shivaspeaks merged 1 commit into
grpc:masterfrom
shivaspeaks:move-ATTR_ADDRESS_NAME-to-api

Conversation

@shivaspeaks

@shivaspeaks shivaspeaks commented Sep 23, 2026 •

Copy link
Copy Markdown
Member

Correction to the implementation of gRFC A81-xds-authority-rewriting. The proposal says:

Note that the resolver attribute used here should be a general-purpose one, not something specific to EDS;

The endpoint hostname attribute from gRFC A81 is currently defined in XdsInternalAttributes, which makes it unreachable from other modules.

Move the key to EquivalentAddressGroup alongside the other endpoint attributes and re-export it via InternalEquivalentAddressGroup. XdsInternalAttributes held nothing else, so it is removed and its callers now reference the key directly.

This is needed by the autosharding LB policy gRFC A119, which keys its endpoint map on the A81 hostname. autosharding cannot depend on xds because xds will depend on autosharding.

CC: @sauravzg

@shivaspeaks
shivaspeaks requested review from ejona86 and sauravzg and removed request for ejona86 September 23, 2026 10:39
@shivaspeaks
shivaspeaks merged commit 4d0d548 into grpc:master Sep 24, 2026
17 of 18 checks passed
/**
* Name associated with individual address, if available (e.g., DNS name).
*/
public static final Attributes.Key<String> ATTR_ADDRESS_NAME =

@ejona86 ejona86 Sep 24, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this exist? Can't all callers of this use EquivalentAddressGroup directly?

The point of this class is if there's something we don't want to make public API. So it would be useful if the attribute wasn't in EAG at all.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in the follow-up: #13076

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, nm. I failed to notice it wasn't public in EAG.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then you also said

So it would be useful if the attribute wasn't in EAG at all.

So we can keep it in internal only. What problem will it have?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What purpose does it serve defining in EAG at all?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When building with Bazel, we use a two-stage build and build Internal* files separately. So if this attribute was used in io.grpc itself, it can't use the Internal* copy. In this case it isn't used in io.grpc at all so it really doesn't matter, but the normal pattern is to just make Internal* accessors so it could be used in io.grpc.

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.

3 participants