Autogenerated update (2019-06-07)

Update:
- appengine_v1
- appengine_v1alpha
- appengine_v1beta
- cloudtasks_v2beta2
- container_v1beta1
- genomics_v1
- genomics_v1alpha2
- genomics_v2alpha1
- monitoring_v3
- remotebuildexecution_v1
- remotebuildexecution_v1alpha
- remotebuildexecution_v2
- runtimeconfig_v1
- runtimeconfig_v1beta1
- serviceconsumermanagement_v1
- servicenetworking_v1
- servicenetworking_v1beta
- serviceusage_v1
- serviceusage_v1beta1
- storage_v1

generated/google/apis/appengine_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/appengine/docs/admin-api/
     module AppengineV1
       VERSION = 'V1'
-      REVISION = '20190503'
+      REVISION = '20190531'
 
       # View and manage your applications deployed on Google App Engine
       AUTH_APPENGINE_ADMIN = 'https://www.googleapis.com/auth/appengine.admin'

generated/google/apis/appengine_v1/classes.rb

@@ -1796,38 +1796,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:
+        # (https://github.com/grpc). Each Status message contains three pieces of data:
-        # Simple to use and understand for most users
+        # error code, error message, and error details.You can find out more about this
-        # Flexible enough to meet unexpected needsOverviewThe Status message contains
+        # error model and how to work with it in the API Design Guide (https://cloud.
-        # three pieces of data: error code, error message, and error details. The error
+        # google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::AppengineV1::Status]
         attr_accessor :error
@@ -2445,38 +2417,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:
+      # (https://github.com/grpc). Each Status message contains three pieces of data:
-      # Simple to use and understand for most users
+      # error code, error message, and error details.You can find out more about this
-      # Flexible enough to meet unexpected needsOverviewThe Status message contains
+      # error model and how to work with it in the API Design Guide (https://cloud.
-      # three pieces of data: error code, error message, and error details. The error
+      # google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/appengine_v1alpha.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/appengine/docs/admin-api/
     module AppengineV1alpha
       VERSION = 'V1alpha'
-      REVISION = '20190503'
+      REVISION = '20190531'
 
       # View and manage your applications deployed on Google App Engine
       AUTH_APPENGINE_ADMIN = 'https://www.googleapis.com/auth/appengine.admin'

generated/google/apis/appengine_v1alpha/classes.rb

@@ -528,38 +528,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:
+        # (https://github.com/grpc). Each Status message contains three pieces of data:
-        # Simple to use and understand for most users
+        # error code, error message, and error details.You can find out more about this
-        # Flexible enough to meet unexpected needsOverviewThe Status message contains
+        # error model and how to work with it in the API Design Guide (https://cloud.
-        # three pieces of data: error code, error message, and error details. The error
+        # google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::AppengineV1alpha::Status]
         attr_accessor :error
@@ -867,38 +839,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:
+      # (https://github.com/grpc). Each Status message contains three pieces of data:
-      # Simple to use and understand for most users
+      # error code, error message, and error details.You can find out more about this
-      # Flexible enough to meet unexpected needsOverviewThe Status message contains
+      # error model and how to work with it in the API Design Guide (https://cloud.
-      # three pieces of data: error code, error message, and error details. The error
+      # google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/appengine_v1beta.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/appengine/docs/admin-api/
     module AppengineV1beta
       VERSION = 'V1beta'
-      REVISION = '20190503'
+      REVISION = '20190531'
 
       # View and manage your applications deployed on Google App Engine
       AUTH_APPENGINE_ADMIN = 'https://www.googleapis.com/auth/appengine.admin'

generated/google/apis/appengine_v1beta/classes.rb

@@ -1913,38 +1913,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:
+        # (https://github.com/grpc). Each Status message contains three pieces of data:
-        # Simple to use and understand for most users
+        # error code, error message, and error details.You can find out more about this
-        # Flexible enough to meet unexpected needsOverviewThe Status message contains
+        # error model and how to work with it in the API Design Guide (https://cloud.
-        # three pieces of data: error code, error message, and error details. The error
+        # google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::AppengineV1beta::Status]
         attr_accessor :error
@@ -2562,38 +2534,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:
+      # (https://github.com/grpc). Each Status message contains three pieces of data:
-      # Simple to use and understand for most users
+      # error code, error message, and error details.You can find out more about this
-      # Flexible enough to meet unexpected needsOverviewThe Status message contains
+      # error model and how to work with it in the API Design Guide (https://cloud.
-      # three pieces of data: error code, error message, and error details. The error
+      # google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/cloudtasks_v2beta2.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/tasks/
     module CloudtasksV2beta2
       VERSION = 'V2beta2'
-      REVISION = '20190513'
+      REVISION = '20190531'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/cloudtasks_v2beta2/classes.rb

@@ -404,43 +404,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `responseStatus`
         # @return [Google::Apis::CloudtasksV2beta2::Status]
         attr_accessor :response_status
@@ -1512,43 +1479,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/container_v1beta1.rb

@@ -26,7 +26,7 @@ module Google
     # @see https://cloud.google.com/container-engine/
     module ContainerV1beta1
       VERSION = 'V1beta1'
-      REVISION = '20190524'
+      REVISION = '20190527'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/container_v1beta1/classes.rb

@@ -2171,6 +2171,12 @@ module Google
         # "kube-env"
         # "startup-script"
         # "user-data"
+        # "disable-address-manager"
+        # "windows-startup-script-ps1"
+        # "common-psm1"
+        # "k8s-node-setup-psm1"
+        # "install-ssh-psm1"
+        # "user-profile-psm1"
         # Values are free-form strings, and only have meaning as interpreted by
         # the image running in the instance. The only restriction placed on them is
         # that each value's size must be less than or equal to 32 KB.

generated/google/apis/genomics_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/genomics
     module GenomicsV1
       VERSION = 'V1'
-      REVISION = '20190507'
+      REVISION = '20190606'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/genomics_v1/classes.rb

@@ -316,43 +316,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::GenomicsV1::Status]
         attr_accessor :error
@@ -570,43 +537,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/genomics_v1alpha2.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/genomics
     module GenomicsV1alpha2
       VERSION = 'V1alpha2'
-      REVISION = '20190507'
+      REVISION = '20190606'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/genomics_v1alpha2/classes.rb

@@ -569,43 +569,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::GenomicsV1alpha2::Status]
         attr_accessor :error
@@ -1324,43 +1291,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/genomics_v2alpha1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/genomics
     module GenomicsV2alpha1
       VERSION = 'V2alpha1'
-      REVISION = '20190507'
+      REVISION = '20190606'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/genomics_v2alpha1/classes.rb

@@ -136,7 +136,7 @@ module Google
         # An optional name for the container. The container hostname will be set to
         # this name, making it useful for inter-container communication. The name
         # must contain only upper and lowercase alphanumeric characters and hypens
-        # and cannot start with a hypen.
+        # and cannot start with a hyphen.
         # Corresponds to the JSON property `name`
         # @return [String]
         attr_accessor :name
@@ -222,43 +222,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `result`
         # @return [Google::Apis::GenomicsV2alpha1::Status]
         attr_accessor :result
@@ -479,7 +446,7 @@ module Google
       
         # A user-supplied name for the disk. Used when mounting the disk into
         # actions. The name must contain only upper and lowercase alphanumeric
-        # characters and hypens and cannot start with a hypen.
+        # characters and hypens and cannot start with a hyphen.
         # Corresponds to the JSON property `name`
         # @return [String]
         attr_accessor :name
@@ -788,43 +755,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::GenomicsV2alpha1::Status]
         attr_accessor :error
@@ -1213,43 +1147,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/monitoring_v3.rb

@@ -22,12 +22,15 @@ module Google
     #
     # Manages your Stackdriver Monitoring data and configurations. Most projects
     # must be associated with a Stackdriver account, with a few exceptions as noted
-    # on the individual method pages.
+    # on the individual method pages. The table entries below are presented in
+    # alphabetical order, not in order of common use. For explanations of the
+    # concepts found in the table entries, read the Stackdriver Monitoring
+    # documentation.
     #
     # @see https://cloud.google.com/monitoring/api/
     module MonitoringV3
       VERSION = 'V3'
-      REVISION = '20190526'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/monitoring_v3/classes.rb

@@ -344,38 +344,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:
+        # (https://github.com/grpc). Each Status message contains three pieces of data:
-        # Simple to use and understand for most users
+        # error code, error message, and error details.You can find out more about this
-        # Flexible enough to meet unexpected needsOverviewThe Status message contains
+        # error model and how to work with it in the API Design Guide (https://cloud.
-        # three pieces of data: error code, error message, and error details. The error
+        # google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::MonitoringV3::Status]
         attr_accessor :error
@@ -442,38 +414,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:
+        # (https://github.com/grpc). Each Status message contains three pieces of data:
-        # Simple to use and understand for most users
+        # error code, error message, and error details.You can find out more about this
-        # Flexible enough to meet unexpected needsOverviewThe Status message contains
+        # error model and how to work with it in the API Design Guide (https://cloud.
-        # three pieces of data: error code, error message, and error details. The error
+        # google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::MonitoringV3::Status]
         attr_accessor :error
@@ -2028,7 +1972,7 @@ module Google
       # the use of the labels "instance_id" and "zone" to identify particular VM
       # instances.Different APIs can support different monitored resource types. APIs
       # generally provide a list method that returns the monitored resource
-      # descriptors used by the API.
+      # descriptors used by the API.Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       
@@ -2482,38 +2426,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:
+      # (https://github.com/grpc). Each Status message contains three pieces of data:
-      # Simple to use and understand for most users
+      # error code, error message, and error details.You can find out more about this
-      # Flexible enough to meet unexpected needsOverviewThe Status message contains
+      # error model and how to work with it in the API Design Guide (https://cloud.
-      # three pieces of data: error code, error message, and error details. The error
+      # google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/monitoring_v3/service.rb

@@ -24,7 +24,10 @@ module Google
       #
       # Manages your Stackdriver Monitoring data and configurations. Most projects
       #  must be associated with a Stackdriver account, with a few exceptions as noted
-      #  on the individual method pages.
+      #  on the individual method pages. The table entries below are presented in
+      #  alphabetical order, not in order of common use. For explanations of the
+      #  concepts found in the table entries, read the Stackdriver Monitoring
+      #  documentation.
       #
       # @example
       #    require 'google/apis/monitoring_v3'

generated/google/apis/remotebuildexecution_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/remote-build-execution/docs/
     module RemotebuildexecutionV1
       VERSION = 'V1'
-      REVISION = '20190521'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/remotebuildexecution_v1/classes.rb

@@ -801,43 +801,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
         attr_accessor :status
@@ -2538,43 +2505,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
         attr_accessor :status
@@ -3207,43 +3141,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
         attr_accessor :status
@@ -3672,43 +3573,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
         attr_accessor :error
@@ -3775,43 +3643,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class GoogleRpcStatus
         include Google::Apis::Core::Hashable
       

generated/google/apis/remotebuildexecution_v1alpha.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/remote-build-execution/docs/
     module RemotebuildexecutionV1alpha
       VERSION = 'V1alpha'
-      REVISION = '20190521'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/remotebuildexecution_v1alpha/classes.rb

@@ -801,43 +801,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
         attr_accessor :status
@@ -2519,43 +2486,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
         attr_accessor :status
@@ -3188,43 +3122,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
         attr_accessor :status
@@ -3615,43 +3516,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
         attr_accessor :error
@@ -3699,43 +3567,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class GoogleRpcStatus
         include Google::Apis::Core::Hashable
       

generated/google/apis/remotebuildexecution_v2.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/remote-build-execution/docs/
     module RemotebuildexecutionV2
       VERSION = 'V2'
-      REVISION = '20190521'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/remotebuildexecution_v2/classes.rb

@@ -472,43 +472,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
         attr_accessor :status
@@ -654,43 +621,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
         attr_accessor :status
@@ -1255,43 +1189,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
         attr_accessor :status
@@ -3272,43 +3173,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
         attr_accessor :status
@@ -3941,43 +3809,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `status`
         # @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
         attr_accessor :status
@@ -4368,43 +4203,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
         attr_accessor :error
@@ -4452,43 +4254,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class GoogleRpcStatus
         include Google::Apis::Core::Hashable
       

generated/google/apis/runtimeconfig_v1.rb

@@ -28,7 +28,7 @@ module Google
     # @see https://cloud.google.com/deployment-manager/runtime-configurator/
     module RuntimeconfigV1
       VERSION = 'V1'
-      REVISION = '20190506'
+      REVISION = '20190603'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/runtimeconfig_v1/classes.rb

@@ -94,43 +94,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::RuntimeconfigV1::Status]
         attr_accessor :error
@@ -178,43 +145,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       

generated/google/apis/runtimeconfig_v1beta1.rb

@@ -28,7 +28,7 @@ module Google
     # @see https://cloud.google.com/deployment-manager/runtime-configurator/
     module RuntimeconfigV1beta1
       VERSION = 'V1beta1'
-      REVISION = '20190506'
+      REVISION = '20190603'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/runtimeconfig_v1beta1/classes.rb

@@ -309,43 +309,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::RuntimeconfigV1beta1::Status]
         attr_accessor :error
@@ -560,43 +527,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:
+      # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-      # - Simple to use and understand for most users
+      # three pieces of data: error code, error message, and error details.
-      # - Flexible enough to meet unexpected needs
+      # You can find out more about this error model and how to work with it in the
-      # # Overview
+      # [API Design Guide](https://cloud.google.com/apis/design/errors).
-      # 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.
       class Status
         include Google::Apis::Core::Hashable
       
@@ -775,43 +709,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:
+        # used by [gRPC](https://github.com/grpc). Each `Status` message contains
-        # - Simple to use and understand for most users
+        # three pieces of data: error code, error message, and error details.
-        # - Flexible enough to meet unexpected needs
+        # You can find out more about this error model and how to work with it in the
-        # # Overview
+        # [API Design Guide](https://cloud.google.com/apis/design/errors).
-        # 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::RuntimeconfigV1beta1::Status]
         attr_accessor :error

generated/google/apis/serviceconsumermanagement_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/service-consumer-management/docs/overview
     module ServiceconsumermanagementV1
       VERSION = 'V1'
-      REVISION = '20190530'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/serviceconsumermanagement_v1/classes.rb

@@ -2138,6 +2138,7 @@ module Google
       # Different APIs can support different monitored resource types. APIs generally
       # provide a `list` method that returns the monitored resource descriptors used
       # by the API.
+      # Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       

generated/google/apis/servicenetworking_v1.rb

@@ -26,7 +26,7 @@ module Google
     # @see https://cloud.google.com/service-infrastructure/docs/service-networking/getting-started
     module ServicenetworkingV1
       VERSION = 'V1'
-      REVISION = '20190530'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/servicenetworking_v1/classes.rb

@@ -2153,6 +2153,7 @@ module Google
       # Different APIs can support different monitored resource types. APIs generally
       # provide a `list` method that returns the monitored resource descriptors used
       # by the API.
+      # Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       

generated/google/apis/servicenetworking_v1beta.rb

@@ -26,7 +26,7 @@ module Google
     # @see https://cloud.google.com/service-infrastructure/docs/service-networking/getting-started
     module ServicenetworkingV1beta
       VERSION = 'V1beta'
-      REVISION = '20190530'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/servicenetworking_v1beta/classes.rb

@@ -2093,6 +2093,7 @@ module Google
       # Different APIs can support different monitored resource types. APIs generally
       # provide a `list` method that returns the monitored resource descriptors used
       # by the API.
+      # Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       

generated/google/apis/serviceusage_v1.rb

@@ -27,7 +27,7 @@ module Google
     # @see https://cloud.google.com/service-usage/
     module ServiceusageV1
       VERSION = 'V1'
-      REVISION = '20190530'
+      REVISION = '20190605'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/serviceusage_v1/classes.rb

@@ -2847,6 +2847,7 @@ module Google
       # Different APIs can support different monitored resource types. APIs generally
       # provide a `list` method that returns the monitored resource descriptors used
       # by the API.
+      # Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       

generated/google/apis/serviceusage_v1beta1.rb

@@ -27,7 +27,7 @@ module Google
     # @see https://cloud.google.com/service-usage/
     module ServiceusageV1beta1
       VERSION = 'V1beta1'
-      REVISION = '20190530'
+      REVISION = '20190605'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/serviceusage_v1beta1/classes.rb

@@ -2823,6 +2823,7 @@ module Google
       # Different APIs can support different monitored resource types. APIs generally
       # provide a `list` method that returns the monitored resource descriptors used
       # by the API.
+      # Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       

generated/google/apis/storage_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://developers.google.com/storage/docs/json_api/
     module StorageV1
       VERSION = 'V1'
-      REVISION = '20190426'
+      REVISION = '20190523'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

generated/google/apis/storage_v1/classes.rb

@@ -987,12 +987,6 @@ module Google
         # @return [String]
         attr_accessor :expression
       
-        # The kind of item this is. For storage, this is always storage#expr. This field
-        # is ignored on input.
-        # Corresponds to the JSON property `kind`
-        # @return [String]
-        attr_accessor :kind
-      
         # An optional string indicating the location of the expression for error
         # reporting, e.g. a file name and a position in the file.
         # Corresponds to the JSON property `location`
@@ -1013,7 +1007,6 @@ module Google
         def update!(**args)
           @description = args[:description] if args.key?(:description)
           @expression = args[:expression] if args.key?(:expression)
-          @kind = args[:kind] if args.key?(:kind)
           @location = args[:location] if args.key?(:location)
           @title = args[:title] if args.key?(:title)
         end

generated/google/apis/storage_v1/representations.rb

@@ -529,7 +529,6 @@ module Google
         class Representation < Google::Apis::Core::JsonRepresentation
           property :description, as: 'description'
           property :expression, as: 'expression'
-          property :kind, as: 'kind'
           property :location, as: 'location'
           property :title, as: 'title'
         end