Autogenerated update (2019-06-16)

Update:
- bigtableadmin_v1
- bigtableadmin_v2
- dataproc_v1
- dataproc_v1beta2
- dns_v1beta2
- file_v1beta1

generated/google/apis/dataproc_v1beta2/classes.rb

@@ -1969,38 +1969,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 needsOverviewThe 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 mappingThe 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 usesThe 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.
+        # (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::DataprocV1beta2::Status]
         attr_accessor :error
@@ -2818,38 +2790,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 needsOverviewThe 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 mappingThe 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 usesThe 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.
+      # (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