This is part of our long-term project plans but it's not on any near-term road map.

Is there a walk around solution for python to do load balancing based on name resolving currently?

@nathanielmanistaatgoogle any updates on when this will be picked up?
We are currently using custom resolvers in Java and Golang and would like to offer the same thing for our Python users.

@jhaals: @srini100 is more likely than I to have up-to-date information.

@jhaals, there is no immediate plan to add name resolver plugin in gRPC Python. There are some discussions going on around making the Core API public but that's in very early stage. Will update when there is more clarity on this.

@jhaals, what's your time frame to require this feature?

I can't speak in time frames but we have multiple Python only teams that expressed an interest in adopting gRPC. Service to service name resolution is entirely DNS(SRV) based for discovering ports and endpoints.

@srini100 Hi, what are the required steps for adding this API?
Does it require separate proposal steps or can I send pull request to grpc-core ~now and we will iterate in it?

As @srini100 mentioned above, we do have work going on now to make our current internal resolver API public, but that is part of a larger project and will probably take at least a couple of quarters. However, I think we could provide a Python resolver API without having to wait for those changes. We could do this in two steps:

1. Define a C-core surface API for resolver plugins. This is different from our current internal API (which is actually C++); it would be implemented as a shim that plugs into our existing C++ API but delegates its functionality to a resolver written against the new C-core surface API.

2. Define a Python resolver API. This would be implemented as part of the gRPC Python layer that sits on top of C-core; it would basically convert between the C-core API described in the previous step and the Python API.

These would probably best be done as two different projects. I don't think we have any cycles to actually do either of them right now, but if someone wants to contribute, we can provide guidance and reviews from our end. I can be the contact point for the first part. @srini100 can find someone to help with the second part.

Please let me know if you have any questions about any of this.

@markdroth Thanks for the elaborate answer. I've linked the pull request for grpc-core part and would welcome any feedback.

This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 180 days. It will be closed automatically if no further update occurs in 1 day. Thank you for your contributions!

This feature is still on-demand.

This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 180 days. It will be closed automatically if no further update occurs in 1 day. Thank you for your contributions!

Again, this feature is still on-demand.

Any updates?

Want NameResolver in Python as well. This feature is still on-demand.

NameResolver in python feature is still on-demand.

Thanks for bring this up, we understand that this is still needed by our users, but there are some internal changes (in grpc core) needs to be made before the change can start at all (It's called EventEngine). Once the eventEngine changes merged, we'll still need extra hands to make this happen, if someone is willing to help, they'll need write a gRFC first and then implement it. We're more than happy to provide more information with video call :)

This is part of our long-term project plans but it's not on any near-term road map.

How long term are we talking?

How long term are we talking?

Given that the comment you quoted is from 2018, pretty long term.

On a more serious note, this is one of the more important long-standing gaps in the Python API as I see it. The issue is just technical complexity. This will require making many currently private Core APIs public. The Core maintainers have been hesitant to do that for the past several years because we're in the middle of a major overhaul of how Core works (Event Engine). Luckily, that effort is starting to wrap up, so the time might be right to jump on this soon.

Just thought I would check on the status of this since it's been over a year since the last update. This is a pretty desirable feature for us.