Make CallCredentials non-experimental #1914
Comments
|
not stabilized yet, keep unscheduled |
|
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 |
|
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 |
As discussed in grpc#1914, we need CallCredentials and MoreCallCredentials to be stable, but there's less of a strong need for the contents of CallCredentials to be stable. We're willing to commit to the name, without needing to commit to the plumbing.
As discussed in #1914, we need CallCredentials and MoreCallCredentials to be stable, but there's less of a strong need for the contents of CallCredentials to be stable. We're willing to commit to the name, without needing to commit to the plumbing.
|
Possibly need to fix: there is no way to cancel an async CallCredential. C has a cancel in its API. |
|
Hmm... maybe that is an internal API. Because I also see this API which doesn't have a cancel. |
|
API review:
|
|
Stabilized in #10208. The |
This is a tracking issue for removing
@ExperimentalApifromCallCredentials-related API.The text was updated successfully, but these errors were encountered: