grpc-java
grpc-java copied to clipboard
grpc
Make CallCredentials non-experimental
This is a tracking issue for removing @ExperimentalApi from CallCredentials-related API.
This seems critical for client stability - without this being non-experimental, there is no non-experimental way to make gRPC calls that require credentials, effectively making it so that gRPC doesn't have a "complete" GA surface.
Agreed, this is very important to stabilize. If push comes to shove, there is one trick we could do: we could stabilize the usages, but not the implementations. So that would mean CallOptions.withCallCredentials and MoreCallCredentials could be stable, even though the interface may change. We'd basically say that the name would remain the same and MoreCallCredentials would remain compatible. grpc-auth would need to be version-pinned (if it isn't already) to the same version of grpc-core, but that shouldn't cause much issue.
I'm assigning this to myself to remove most of the experimental api tags as I mentioned in the last comment, but I'm not going to end up stabilizing all of the API.
Would it be possible not to have Google credentials in the core gRPC libraries? gRPC as a core RPC framework probably don't need Google credentials.
@saturnism, only grpc-auth depends on google-auth-library-credentials. Also, "Google credentials" isn't in google-auth-library-credentials, but in google-auth-library-oauth2-http. CallCredentials is in grpc-core, so there should be no unnecessary dependencies.
it seems grpc-auth is only dealing w/ google credentials. @garrettjonesgoogle do you actually need this from gcloud-java? It was a discussion point of dependency conflicts.
grpc-auth feels very much core, as the core auth supplement library; is there a plan to add additional auth providers to grpc-auth?
would it make sense to have submodule e.g. grpc-auth-google? The point is that... if you need auth in gRPC, you don't necessarily need Google credentials.
@saturnism, your comments are off-topic for this issue (CallCredentials is in grpc-core and has no external dependencies). Let's move the conversation to the freshly-created #3280
API review:
- Ready to stabilize
- Obviously will remove the thisUsesUnstableApi() method. Probably in two phases: give it an implementation and make it deprecated, later delete.
Stabilized in #10208.
The thisUsesUnstableApi() method has been marked deprecated to give implementers time to stop using it until we remove the method in the future. I will leave this issue open to track the removal of the method.
