Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add XdsDirectory to get d2 service and cluster names from INDIS #1038

Merged
merged 20 commits into from
Jan 30, 2025

Conversation

bohhyang
Copy link
Contributor

@bohhyang bohhyang commented Jan 15, 2025

Summary

Support getting d2 service and cluster name lists from INDIS with Xds load balancer. This is needed by some apps (like d2-proxy) that need to read the names to migrate to INDIS read.

Note that observer hasn't supported the resource D2ClusterOrServiceName yet, so build and test are failing.

Test

UT. QEI test with d2-proxy. The names is fetched and served correctly.

@bohhyang bohhyang requested a review from PapaCharlie January 24, 2025 02:46
Copy link
Collaborator

@brycezhongqing brycezhongqing left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for the contribution.

…nd unlock write lock after checking isUpdating flag
@bohhyang bohhyang merged commit b2da251 into master Jan 30, 2025
2 checks passed
@bohhyang bohhyang deleted the by/directory branch January 30, 2025 01:19
PapaCharlie added a commit to linkedin/diderot that referenced this pull request Feb 7, 2025
Because there is no explicit provision for unknown resource types in the
xDS protocol, the server implementation had to make a bunch of
assumptions about how it should respond. These assumptions incidentally
violated the xDS protocol NACK/ACK flow. Instead, the behavior should be
handed off to the `ResourceLocator` implementation so that it can decide
what to do. This also allows the simplification of the `ResourceLocator`
interface, which is an added benefit.

Note that this change is backwards incompatible, so will need to be
bumped carefully.

I have tested this manually using the bad version of rest.li which
triggered this loop (linkedin/rest.li#1038), and
can confirm that this behavior is fixed.
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