vendor update for CSI 0.3.0

vendor/google.golang.org/grpc/Documentation/concurrency.md

@@ -0,0 +1,33 @@
+# Concurrency
+
+In general, gRPC-go provides a concurrency-friendly API. What follows are some
+guidelines.
+
+## Clients
+
+A [ClientConn][client-conn] can safely be accessed concurrently. Using
+[helloworld][helloworld] as an example, one could share the `ClientConn` across
+multiple goroutines to create multiple `GreeterClient` types. In this case, RPCs
+would be sent in parallel.
+
+## Streams
+
+When using streams, one must take care to avoid calling either `SendMsg` or
+`RecvMsg` multiple times against the same [Stream][stream] from different
+goroutines. In other words, it's safe to have a goroutine calling `SendMsg` and
+another goroutine calling `RecvMsg` on the same stream at the same time. But it
+is not safe to call `SendMsg` on the same stream in different goroutines, or to
+call `RecvMsg` on the same stream in different goroutines.
+
+## Servers
+
+Each RPC handler attached to a registered server will be invoked in its own
+goroutine. For example, [SayHello][say-hello] will be invoked in its own
+goroutine. The same is true for service handlers for streaming RPCs, as seen
+in the route guide example [here][route-guide-stream].
+
+[helloworld]: https://github.com/grpc/grpc-go/blob/master/examples/helloworld/greeter_client/main.go#L43
+[client-conn]: https://godoc.org/google.golang.org/grpc#ClientConn
+[stream]: https://godoc.org/google.golang.org/grpc#Stream
+[say-hello]: https://github.com/grpc/grpc-go/blob/master/examples/helloworld/greeter_server/main.go#L41
+[route-guide-stream]: https://github.com/grpc/grpc-go/blob/master/examples/route_guide/server/server.go#L126

vendor/google.golang.org/grpc/Documentation/grpc-auth-support.md

@@ -21,6 +21,43 @@ server := grpc.NewServer(grpc.Creds(creds))
 server.Serve(lis)
 ```
 
+# OAuth2
+
+For an example of how to configure client and server to use OAuth2 tokens, see
+[here](https://github.com/grpc/grpc-go/blob/master/examples/oauth/).
+
+## Validating a token on the server
+
+Clients may use
+[metadata.MD](https://godoc.org/google.golang.org/grpc/metadata#MD)
+to store tokens and other authentication-related data. To gain access to the
+`metadata.MD` object, a server may use
+[metadata.FromIncomingContext](https://godoc.org/google.golang.org/grpc/metadata#FromIncomingContext).
+With a reference to `metadata.MD` on the server, one needs to simply lookup the
+`authorization` key. Note, all keys stored within `metadata.MD` are normalized
+to lowercase. See [here](https://godoc.org/google.golang.org/grpc/metadata#New).
+
+It is possible to configure token validation for all RPCs using an interceptor.
+A server may configure either a
+[grpc.UnaryInterceptor](https://godoc.org/google.golang.org/grpc#UnaryInterceptor)
+or a
+[grpc.StreamInterceptor](https://godoc.org/google.golang.org/grpc#StreamInterceptor).
+
+## Adding a token to all outgoing client RPCs
+
+To send an OAuth2 token with each RPC, a client may configure the
+`grpc.DialOption`
+[grpc.WithPerRPCCredentials](https://godoc.org/google.golang.org/grpc#WithPerRPCCredentials).
+Alternatively, a client may also use the `grpc.CallOption`
+[grpc.PerRPCCredentials](https://godoc.org/google.golang.org/grpc#PerRPCCredentials)
+on each invocation of an RPC.
+
+To create a `credentials.PerRPCCredentials`, use
+[oauth.NewOauthAccess](https://godoc.org/google.golang.org/grpc/credentials/oauth#NewOauthAccess).
+Note, the OAuth2 implementation of `grpc.PerRPCCredentials` requires a client to use
+[grpc.WithTransportCredentials](https://godoc.org/google.golang.org/grpc#WithTransportCredentials)
+to prevent any insecure transmission of tokens.
+
 # Authenticating with Google
 
 ## Google Compute Engine (GCE)

vendor/google.golang.org/grpc/Documentation/log_levels.md

@@ -0,0 +1,49 @@
+# Log Levels
+
+This document describes the different log levels supported by the grpc-go
+library, and under what conditions they should be used.
+
+### Info
+
+Info messages are for informational purposes and may aid in the debugging of
+applications or the gRPC library.
+
+Examples:
+- The name resolver received an update.
+- The balancer updated its picker.
+- Significant gRPC state is changing.
+
+At verbosity of 0 (the default), any single info message should not be output
+more than once every 5 minutes under normal operation.
+
+### Warning
+
+Warning messages indicate problems that are non-fatal for the application, but
+could lead to unexpected behavior or subsequent errors.
+
+Examples:
+- Resolver could not resolve target name.
+- Error received while connecting to a server.
+- Lost or corrupt connection with remote endpoint.
+
+### Error
+
+Error messages represent errors in the usage of gRPC that cannot be returned to
+the application as errors, or internal gRPC-Go errors that are recoverable.
+
+Internal errors are detected during gRPC tests and will result in test failures.
+
+Examples:
+- Invalid arguments passed to a function that cannot return an error.
+- An internal error that cannot be returned or would be inappropriate to return
+  to the user.
+
+### Fatal
+
+Fatal errors are severe internal errors that are unrecoverable.  These lead
+directly to panics, and are avoided as much as possible.
+
+Example:
+- Internal invariant was violated.
+- User attempted an action that cannot return an error gracefully, but would
+  lead to an invalid state if performed.

vendor/google.golang.org/grpc/Documentation/rpc-errors.md

@@ -0,0 +1,68 @@
+# RPC Errors
+
+All service method handlers should return `nil` or errors from the
+`status.Status` type. Clients have direct access to the errors.
+
+Upon encountering an error, a gRPC server method handler should create a
+`status.Status`. In typical usage, one would use [status.New][new-status]
+passing in an appropriate [codes.Code][code] as well as a description of the
+error to produce a `status.Status`. Calling [status.Err][status-err] converts
+the `status.Status` type into an `error`. As a convenience method, there is also
+[status.Error][status-error] which obviates the conversion step. Compare:
+
+```
+st := status.New(codes.NotFound, "some description")
+err := st.Err()
+
+// vs.
+
+err := status.Error(codes.NotFound, "some description")
+```
+
+## Adding additional details to errors
+
+In some cases, it may be necessary to add details for a particular error on the
+server side. The [status.WithDetails][with-details] method exists for this
+purpose. Clients may then read those details by first converting the plain
+`error` type back to a [status.Status][status] and then using
+[status.Details][details].
+
+## Example
+
+The [example][example] demonstrates the API discussed above and shows how to add
+information about rate limits to the error message using `status.Status`.
+
+To run the example, first start the server:
+
+```
+$ go run examples/rpc_errors/server/main.go
+```
+
+In a separate session, run the client:
+
+```
+$ go run examples/rpc_errors/client/main.go
+```
+
+On the first run of the client, all is well:
+
+```
+2018/03/12 19:39:33 Greeting: Hello world
+```
+
+Upon running the client a second time, the client exceeds the rate limit and
+receives an error with details:
+
+```
+2018/03/19 16:42:01 Quota failure: violations:<subject:"name:world" description:"Limit one greeting per person" >
+exit status 1
+```
+
+[status]:       https://godoc.org/google.golang.org/grpc/status#Status
+[new-status]:   https://godoc.org/google.golang.org/grpc/status#New
+[code]:         https://godoc.org/google.golang.org/grpc/codes#Code
+[with-details]: https://godoc.org/google.golang.org/grpc/status#Status.WithDetails
+[details]:      https://godoc.org/google.golang.org/grpc/status#Status.Details
+[status-err]:   https://godoc.org/google.golang.org/grpc/status#Status.Err
+[status-error]: https://godoc.org/google.golang.org/grpc/status#Error
+[example]:      https://github.com/grpc/grpc-go/blob/master/examples/rpc_errors

vendor/google.golang.org/grpc/Documentation/stickiness.md

@@ -0,0 +1,46 @@
+# Stickiness
+
+With load balancer, each RPC pick a different backend based on the load
+balancing policy. Stickiness policies try to preserve peers for the duration of
+a session, so that RPCs with the same stickiness key will be directed to the
+same server.
+
+Note that there's only "soft" stickiness now, which means RPCs with the same
+stickienss key could still be sent to different servers. If stickiness is
+critical for the system, server side application level handling is still
+necessary.
+
+## Stickiness Key
+
+A stickiness key works as the session id. RPCs with the same stickiness key will
+be assigned to the same backend.
+
+Stickiness key is set as part of the custom metadata.
+
+## Enable stickiness
+
+Stickiness can be enabled by setting `stickinessKey` field in [service
+config](https://github.com/grpc/grpc/blob/master/doc/service_config.md).
+
+```json
+{
+  "stickinessKey": "sessionid"
+}
+```
+
+The value `sesseionid` will be used as the key of the metadata entry that
+defines the stickiness key for each RPC.
+
+## Send RPC with stickiness
+
+To set the stickiness key for an RPC, set the corresponding metadata. The
+following RPC will be sent with stickiness key `session1`.
+
+```go
+// "sessionid" is the metadata key specified by service config, "session1" is
+// the stickiness key for this RPC.
+md := metadata.Paris("sessionid", "session1")
+
+ctx := metadata.NewOutgoingContext(context.Background(), md)
+resp, err := client.SomeRPC(ctx, req)
+```