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

Replacement API for client/v3/naming package to be compatible with new GRPC1.30+ resolver API. #12614

Merged
merged 1 commit into from
Jan 30, 2021

Conversation

ptabor
Copy link
Contributor

@ptabor ptabor commented Jan 12, 2021

This is not yet implementation, just API definitions.

Please review whether the API is good / can be improved. The goal is to reach agreement about
desired layout of the naming/resolver packages in etcd-3.5+, before investement in the implementation of the API.

We propose here 3 packages:

  • clientv3/naming/endpoints ->
    That is abstraction layer over etcd that allows to write, read &
    watch Endpoints information. It's independent from GRPC API. It hides
    the storage details.

  • clientv3/naming/endpoints/internal ->
    That contains the grpc's compatible Update class to preserve the
    internal JSON mashalling format.

  • clientv3/naming/resolver ->
    That implements the GRPC resolver API, such that etcd can be
    used for connection.Dial in grpc.

Please see the [grpc_naming.md](TLDR: Please take a look at the proposed modified 3.5 grpc_naming user guide document changes & grpcproxy/cluster.go new integration, to see how the new abstractions work.

Note: I'm trying to reach agreement on the vision. I would appreciate (when/if accepted) contributions covering the implementation aspect.

@skyao @mcluseau @scDisorder @xiang90

@ptabor ptabor changed the title POC: Migrate client/v3/naming package to be compatible with new GRPC resolver API. API POC: Migrate client/v3/naming package to be compatible with new GRPC resolver API. Jan 12, 2021
@wenjiaswe wenjiaswe requested a review from gyuho January 14, 2021 19:16
@gyuho gyuho self-assigned this Jan 14, 2021
@ptabor ptabor force-pushed the prepare-to-remove-grpc-naming-package branch from da6fdfd to 4a5fbbf Compare January 14, 2021 22:57
@scDisorder
Copy link

for me it looks the way it must to be
and it resolves an issue by the way of grpc documentation
lgtm

Copy link
Contributor

@gyuho gyuho left a comment

Choose a reason for hiding this comment

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

+1 for the package renaming here. This is mostly moving some of the naming resolution code under client/v3 -- do I understand right?

Can you add more details regarding my comments in the PR?

client/v3/naming/endpoints/endpoints.go Outdated Show resolved Hide resolved
client/v3/naming/doc.go Outdated Show resolved Hide resolved
client/v3/naming/doc.go Outdated Show resolved Hide resolved
client/v3/naming/doc.go Outdated Show resolved Hide resolved
client/v3/naming/doc.go Outdated Show resolved Hide resolved
client/v3/naming/endpoints/endpoints.go Outdated Show resolved Hide resolved
client/v3/naming/endpoints/endpoints.go Outdated Show resolved Hide resolved
@@ -0,0 +1,37 @@
package internal
Copy link
Contributor

Choose a reason for hiding this comment

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

Where do we use this package?

Copy link
Contributor Author

@ptabor ptabor Jan 17, 2021

Choose a reason for hiding this comment

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

Inside implementation of the endpoint.Manager. It describes how we serialize and deserialize the endpoints as JSON, that we persist in etcd.

As client/v3 is being is linked into many customer's application, it's important to distinguish public API surface from implementation details. We could keep it lower-case as well, but I wanted in this PR stress its private.

Copy link
Contributor

Choose a reason for hiding this comment

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

I understand that, but client/v3/naming/endpoints/endpoints_impl.go importing this looks like placeholders and not implemented yet?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. I hope for contributors to implement this within a month. If no one will contribute, I will do the implementation itself.
The endpoints definition is fixed in stone so its why I'm submitting it.

server/proxy/grpcproxy/cluster.go Outdated Show resolved Hide resolved
client/v3/naming/grpc.go Outdated Show resolved Hide resolved
@ptabor ptabor force-pushed the prepare-to-remove-grpc-naming-package branch 2 times, most recently from b9b43de to 11831ce Compare January 18, 2021 13:28
@ptabor
Copy link
Contributor Author

ptabor commented Jan 18, 2021

@gyuho : PTAL

@ptabor ptabor force-pushed the prepare-to-remove-grpc-naming-package branch 3 times, most recently from 85f12bd to 4503591 Compare January 22, 2021 19:59
@ptabor ptabor changed the title API POC: Migrate client/v3/naming package to be compatible with new GRPC resolver API. Replacement API for client/v3/naming package to be compatible with new GRPC1.30+ resolver API. Jan 22, 2021
@ptabor
Copy link
Contributor Author

ptabor commented Jan 22, 2021

@gyuho I changed the PR such that its commitable (I left original naming/grpc.go and introduced the new interfaces side by side, and "stashed" the grpcproxy migration&cleanup ).
I propose merging this PR, to unblock other contributors interested in enabling grpc upgrade.

@scDisorder @dhermes @skyao FYI.

@ptabor ptabor requested a review from gyuho January 22, 2021 20:51
@scDisorder
Copy link

scDisorder commented Jan 25, 2021

glad to see that! seems like there is not so much to handle ahead

i'll be literally in touch, when PR would be merged, you can notify me

@scDisorder
Copy link

scDisorder commented Jan 29, 2021

so how it is going? :)

@ptabor @gyuho

sorry if I do bother you :)

@ptabor
Copy link
Contributor Author

ptabor commented Jan 29, 2021

@gyuho Are you OK with me merging this ?

@@ -0,0 +1,121 @@
package endpoints

// TODO: The API is not yet implemented.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we move this as backlogged GitHub issue? Or put these into internal package? Once we have this public, it's hard to remove. Seems like this has not been implemented?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added the issue:
#12652
I assume this will get implemented as part of 3.5.0 (I will contribute if none else).

Copy link
Contributor

Choose a reason for hiding this comment

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

@ptabor Thanks!

@gyuho
Copy link
Contributor

gyuho commented Jan 30, 2021

endpoints.NewManager(c, "foo")

This has not been implemented "in" etcd, but I understand this is mainly to unblock gRPC dependency upgrades, so we should be ok to leave it not implemented. Or if we aren't going to have example endpoint manager implementation, can we just remove?

This is not yet implementation, just API and tests to be filled
with implementation in next CLs,
tracked by: etcd-io#12652

We propose here 3 packages:
 - clientv3/naming/endpoints ->
    That is abstraction layer over etcd that allows to write, read &
    watch Endpoints information. It's independent from GRPC API. It hides
    the storage details.

 - clientv3/naming/endpoints/internal ->
    That contains the grpc's compatible Update class to preserve the
    internal JSON mashalling format.

 - clientv3/naming/resolver ->
   That implements the GRPC resolver API, such that etcd can be
   used for connection.Dial in grpc.

Please see the grpc_naming.md document changes & grpcproxy/cluster.go
new integration, to see how the new abstractions work.
@ptabor ptabor force-pushed the prepare-to-remove-grpc-naming-package branch from dd79c6c to 5d7c1db Compare January 30, 2021 11:32
@ptabor ptabor merged commit cf2153d into etcd-io:master Jan 30, 2021
@ptabor ptabor deleted the prepare-to-remove-grpc-naming-package branch January 30, 2021 11:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants