Autogenerated update (2019-07-05)

Update:
- bigtableadmin_v2
- dataflow_v1b3
- firebase_v1beta1

generated/google/apis/bigtableadmin_v2/classes.rb

@@ -44,10 +44,11 @@ module Google
         # @return [String]
         attr_accessor :etag
       
-        # Read/write requests may be routed to any cluster in the instance, and will
-        # fail over to another cluster in the event of transient errors or delays.
-        # Choosing this option sacrifices read-your-writes consistency to improve
-        # availability.
+        # Read/write requests are routed to the nearest cluster in the instance, and
+        # will fail over to the nearest cluster that is available in the event of
+        # transient errors or delays. Clusters in a region are considered
+        # equidistant. Choosing this option sacrifices read-your-writes consistency
+        # to improve availability.
         # Corresponds to the JSON property `multiClusterRoutingUseAny`
         # @return [Google::Apis::BigtableadminV2::MultiClusterRoutingUseAny]
         attr_accessor :multi_cluster_routing_use_any
@@ -60,7 +61,7 @@ module Google
         attr_accessor :name
       
         # Unconditionally routes all read/write requests to a specific cluster.
-        # This option preserves read-your-writes consistency, but does not improve
+        # This option preserves read-your-writes consistency but does not improve
         # availability.
         # Corresponds to the JSON property `singleClusterRouting`
         # @return [Google::Apis::BigtableadminV2::SingleClusterRouting]
@@ -569,6 +570,7 @@ module Google
       
         # The name by which the new table should be referred to within the parent
         # instance, e.g., `foobar` rather than `<parent>/tables/foobar`.
+        # Maximum 50 characters.
         # Corresponds to the JSON property `tableId`
         # @return [String]
         attr_accessor :table_id
@@ -1139,10 +1141,11 @@ module Google
         end
       end
       
-      # Read/write requests may be routed to any cluster in the instance, and will
-      # fail over to another cluster in the event of transient errors or delays.
-      # Choosing this option sacrifices read-your-writes consistency to improve
-      # availability.
+      # Read/write requests are routed to the nearest cluster in the instance, and
+      # will fail over to the nearest cluster that is available in the event of
+      # transient errors or delays. Clusters in a region are considered
+      # equidistant. Choosing this option sacrifices read-your-writes consistency
+      # to improve availability.
       class MultiClusterRoutingUseAny
         include Google::Apis::Core::Hashable
       
@@ -1170,43 +1173,10 @@ module Google
       
         # The `Status` type defines a logical error model that is suitable for
         # different programming environments, including REST APIs and RPC APIs. It is
-        # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-        # - Simple to use and understand for most users
-        # - Flexible enough to meet unexpected needs
-        # # Overview
-        # The `Status` message contains three pieces of data: error code, error
-        # message, and error details. The error code should be an enum value of
-        # google.rpc.Code, but it may accept additional error codes if needed.  The
-        # error message should be a developer-facing English message that helps
-        # developers *understand* and *resolve* the error. If a localized user-facing
-        # error message is needed, put the localized message in the error details or
-        # localize it in the client. The optional error details may contain arbitrary
-        # information about the error. There is a predefined set of error detail types
-        # in the package `google.rpc` that can be used for common error conditions.
-        # # Language mapping
-        # The `Status` message is the logical representation of the error model, but it
-        # is not necessarily the actual wire format. When the `Status` message is
-        # exposed in different client libraries and different wire protocols, it can be
-        # mapped differently. For example, it will likely be mapped to some exceptions
-        # in Java, but more likely mapped to some error codes in C.
-        # # Other uses
-        # The error model and the `Status` message can be used in a variety of
-        # environments, either with or without APIs, to provide a
-        # consistent developer experience across different environments.
-        # Example uses of this error model include:
-        # - Partial errors. If a service needs to return partial errors to the client,
-        # it may embed the `Status` in the normal response to indicate the partial
-        # errors.
-        # - Workflow errors. A typical workflow has multiple steps. Each step may
-        # have a `Status` message for error reporting.
-        # - Batch operations. If a client uses batch request and batch response, the
-        # `Status` message should be used directly inside batch response, one for
-        # each error sub-response.
-        # - Asynchronous operations. If an API call embeds asynchronous operation
-        # results in its response, the status of those operations should be
-        # represented directly using the `Status` message.
-        # - Logging. If some API errors are stored in logs, the message `Status` could
-        # be used directly after any stripping needed for security/privacy reasons.
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+        # three pieces of data: error code, error message, and error details.
+        # You can find out more about this error model and how to work with it in the
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::BigtableadminV2::Status]
         attr_accessor :error
@@ -1221,7 +1191,7 @@ module Google
       
         # The server-assigned name, which is only unique within the same service that
         # originally returns it. If you use the default HTTP mapping, the
-        # `name` should have the format of `operations/some/unique/name`.
+        # `name` should be a resource name ending with `operations/`unique_id``.
         # Corresponds to the JSON property `name`
         # @return [String]
         attr_accessor :name
@@ -1430,7 +1400,7 @@ module Google
       end
       
       # Unconditionally routes all read/write requests to a specific cluster.
-      # This option preserves read-your-writes consistency, but does not improve
+      # This option preserves read-your-writes consistency but does not improve
       # availability.
       class SingleClusterRouting
         include Google::Apis::Core::Hashable
@@ -1481,43 +1451,10 @@ module Google
       
       # The `Status` type defines a logical error model that is suitable for
       # different programming environments, including REST APIs and RPC APIs. It is
-      # used by [gRPC](https://github.com/grpc). The error model is designed to be:
-      # - Simple to use and understand for most users
-      # - Flexible enough to meet unexpected needs
-      # # Overview
-      # The `Status` message contains three pieces of data: error code, error
-      # message, and error details. The error code should be an enum value of
-      # google.rpc.Code, but it may accept additional error codes if needed.  The
-      # error message should be a developer-facing English message that helps
-      # developers *understand* and *resolve* the error. If a localized user-facing
-      # error message is needed, put the localized message in the error details or
-      # localize it in the client. The optional error details may contain arbitrary
-      # information about the error. There is a predefined set of error detail types
-      # in the package `google.rpc` that can be used for common error conditions.
-      # # Language mapping
-      # The `Status` message is the logical representation of the error model, but it
-      # is not necessarily the actual wire format. When the `Status` message is
-      # exposed in different client libraries and different wire protocols, it can be
-      # mapped differently. For example, it will likely be mapped to some exceptions
-      # in Java, but more likely mapped to some error codes in C.
-      # # Other uses
-      # The error model and the `Status` message can be used in a variety of
-      # environments, either with or without APIs, to provide a
-      # consistent developer experience across different environments.
-      # Example uses of this error model include:
-      # - Partial errors. If a service needs to return partial errors to the client,
-      # it may embed the `Status` in the normal response to indicate the partial
-      # errors.
-      # - Workflow errors. A typical workflow has multiple steps. Each step may
-      # have a `Status` message for error reporting.
-      # - Batch operations. If a client uses batch request and batch response, the
-      # `Status` message should be used directly inside batch response, one for
-      # each error sub-response.
-      # - Asynchronous operations. If an API call embeds asynchronous operation
-      # results in its response, the status of those operations should be
-      # represented directly using the `Status` message.
-      # - Logging. If some API errors are stored in logs, the message `Status` could
-      # be used directly after any stripping needed for security/privacy reasons.
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+      # three pieces of data: error code, error message, and error details.
+      # You can find out more about this error model and how to work with it in the
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
       class Status
         include Google::Apis::Core::Hashable