Autogenerated update (2019-06-05)

Update:
- cloudbuild_v1
- cloudtasks_v2
- cloudtasks_v2beta3
- language_v1
- language_v1beta1
- language_v1beta2
- ml_v1
- storagetransfer_v1
- youtube_partner_v1

generated/google/apis/cloudbuild_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/cloud-build/docs/
     module CloudbuildV1
       VERSION = 'V1'
-      REVISION = '20190507'
+      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/cloudbuild_v1/classes.rb

@@ -965,43 +965,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::CloudbuildV1::Status]
         attr_accessor :error
@@ -1321,43 +1288,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/cloudtasks_v2.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/tasks/
     module CloudtasksV2
       VERSION = 'V2'
-      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_v2/classes.rb

@@ -295,43 +295,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::CloudtasksV2::Status]
         attr_accessor :response_status
@@ -1147,43 +1114,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/cloudtasks_v2/service.rb

@@ -608,8 +608,7 @@ module Google
         
         # Creates a task and adds it to a queue.
         # Tasks cannot be updated after creation; there is no UpdateTask command.
-        # * For App Engine queues, the maximum task size is
+        # * The maximum task size is 100KB.
-        # 100KB.
         # @param [String] parent
         #   Required.
         #   The queue name. For example:

generated/google/apis/cloudtasks_v2beta3.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/tasks/
     module CloudtasksV2beta3
       VERSION = 'V2beta3'
-      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_v2beta3/classes.rb

@@ -339,43 +339,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::CloudtasksV2beta3::Status]
         attr_accessor :response_status
@@ -567,10 +534,6 @@ module Google
       end
       
       # HTTP request.
-      # Warning: This is an [alpha](https://cloud.google.com/terms/launch-stages)
-      # feature. If you haven't already joined, you can [use this form to sign
-      # up](https://docs.google.com/forms/d/e/
-      # 1FAIpQLSfc4uEy9CBHKYUSdnY1hdhKDCX7julVZHy3imOiR-XrU7bUNQ/viewform).
       # The task will be pushed to the worker as an HTTP request. If the worker
       # or the redirected worker acknowledges the task by returning a successful HTTP
       # response code ([`200` - `299`]), the task will removed from the queue. If
@@ -1397,43 +1360,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
       
@@ -1579,10 +1509,6 @@ module Google
         attr_accessor :first_attempt
       
         # HTTP request.
-        # Warning: This is an [alpha](https://cloud.google.com/terms/launch-stages)
-        # feature. If you haven't already joined, you can [use this form to sign
-        # up](https://docs.google.com/forms/d/e/
-        # 1FAIpQLSfc4uEy9CBHKYUSdnY1hdhKDCX7julVZHy3imOiR-XrU7bUNQ/viewform).
         # The task will be pushed to the worker as an HTTP request. If the worker
         # or the redirected worker acknowledges the task by returning a successful HTTP
         # response code ([`200` - `299`]), the task will removed from the queue. If

generated/google/apis/cloudtasks_v2beta3/service.rb

@@ -608,8 +608,7 @@ module Google
         
         # Creates a task and adds it to a queue.
         # Tasks cannot be updated after creation; there is no UpdateTask command.
-        # * For App Engine queues, the maximum task size is
+        # * The maximum task size is 100KB.
-        # 100KB.
         # @param [String] parent
         #   Required.
         #   The queue name. For example:

generated/google/apis/language_v1.rb

@@ -27,7 +27,7 @@ module Google
     # @see https://cloud.google.com/natural-language/
     module LanguageV1
       VERSION = 'V1'
-      REVISION = '20190514'
+      REVISION = '20190603'
 
       # Apply machine learning models to reveal the structure and meaning of text
       AUTH_CLOUD_LANGUAGE = 'https://www.googleapis.com/auth/cloud-language'

generated/google/apis/language_v1/classes.rb

@@ -771,43 +771,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/language_v1beta1.rb

@@ -27,7 +27,7 @@ module Google
     # @see https://cloud.google.com/natural-language/
     module LanguageV1beta1
       VERSION = 'V1beta1'
-      REVISION = '20190308'
+      REVISION = '20190603'
 
       # Apply machine learning models to reveal the structure and meaning of text
       AUTH_CLOUD_LANGUAGE = 'https://www.googleapis.com/auth/cloud-language'

generated/google/apis/language_v1beta1/classes.rb

@@ -622,43 +622,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/language_v1beta2.rb

@@ -27,7 +27,7 @@ module Google
     # @see https://cloud.google.com/natural-language/
     module LanguageV1beta2
       VERSION = 'V1beta2'
-      REVISION = '20190514'
+      REVISION = '20190603'
 
       # Apply machine learning models to reveal the structure and meaning of text
       AUTH_CLOUD_LANGUAGE = 'https://www.googleapis.com/auth/cloud-language'

generated/google/apis/language_v1beta2/classes.rb

@@ -778,43 +778,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/ml_v1.rb

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

generated/google/apis/ml_v1/classes.rb

@@ -392,9 +392,9 @@ module Google
         # @return [String]
         attr_accessor :goal
       
-        # Optional. The Tensorflow summary tag name to use for optimizing trials. For
+        # Optional. The TensorFlow summary tag name to use for optimizing trials. For
-        # current versions of Tensorflow, this tag name should exactly match what is
+        # current versions of TensorFlow, this tag name should exactly match what is
-        # shown in Tensorboard, including all scopes.  For versions of Tensorflow
+        # shown in TensorBoard, including all scopes.  For versions of TensorFlow
         # prior to 0.12, this should be only the tag passed to tf.Summary.
         # By default, "training/hptuning/metric" will be used.
         # Corresponds to the JSON property `hyperparameterMetricTag`
@@ -1336,6 +1336,11 @@ module Google
         # @return [String]
         attr_accessor :master_type
       
+        # Optional. The maximum job running time. The default is 7 days.
+        # Corresponds to the JSON property `maxRunningTime`
+        # @return [String]
+        attr_accessor :max_running_time
+      
         # Required. The Google Cloud Storage location of the packages with
         # the training program and any additional dependencies.
         # The maximum number of package URIs is 100.
@@ -1449,6 +1454,7 @@ module Google
           @job_dir = args[:job_dir] if args.key?(:job_dir)
           @master_config = args[:master_config] if args.key?(:master_config)
           @master_type = args[:master_type] if args.key?(:master_type)
+          @max_running_time = args[:max_running_time] if args.key?(:max_running_time)
           @package_uris = args[:package_uris] if args.key?(:package_uris)
           @parameter_server_config = args[:parameter_server_config] if args.key?(:parameter_server_config)
           @parameter_server_count = args[:parameter_server_count] if args.key?(:parameter_server_count)
@@ -1484,6 +1490,15 @@ module Google
         # @return [Float]
         attr_accessor :consumed_ml_units
       
+        # The TensorFlow summary tag name used for optimizing hyperparameter tuning
+        # trials. See
+        # [`HyperparameterSpec.hyperparameterMetricTag`](#HyperparameterSpec.FIELDS.
+        # hyperparameter_metric_tag)
+        # for more information. Only set for hyperparameter tuning jobs.
+        # Corresponds to the JSON property `hyperparameterMetricTag`
+        # @return [String]
+        attr_accessor :hyperparameter_metric_tag
+      
         # Whether this job is a built-in Algorithm job.
         # Corresponds to the JSON property `isBuiltInAlgorithmJob`
         # @return [Boolean]
@@ -1511,6 +1526,7 @@ module Google
           @built_in_algorithm_output = args[:built_in_algorithm_output] if args.key?(:built_in_algorithm_output)
           @completed_trial_count = args[:completed_trial_count] if args.key?(:completed_trial_count)
           @consumed_ml_units = args[:consumed_ml_units] if args.key?(:consumed_ml_units)
+          @hyperparameter_metric_tag = args[:hyperparameter_metric_tag] if args.key?(:hyperparameter_metric_tag)
           @is_built_in_algorithm_job = args[:is_built_in_algorithm_job] if args.key?(:is_built_in_algorithm_job)
           @is_hyperparameter_tuning_job = args[:is_hyperparameter_tuning_job] if args.key?(:is_hyperparameter_tuning_job)
           @trials = args[:trials] if args.key?(:trials)
@@ -2148,43 +2164,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::MlV1::GoogleRpcStatus]
         attr_accessor :error
@@ -2251,43 +2234,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/ml_v1/representations.rb

@@ -551,6 +551,7 @@ module Google
           property :master_config, as: 'masterConfig', class: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig, decorator: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig::Representation
       
           property :master_type, as: 'masterType'
+          property :max_running_time, as: 'maxRunningTime'
           collection :package_uris, as: 'packageUris'
           property :parameter_server_config, as: 'parameterServerConfig', class: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig, decorator: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig::Representation
       
@@ -575,6 +576,7 @@ module Google
       
           property :completed_trial_count, :numeric_string => true, as: 'completedTrialCount'
           property :consumed_ml_units, as: 'consumedMLUnits'
+          property :hyperparameter_metric_tag, as: 'hyperparameterMetricTag'
           property :is_built_in_algorithm_job, as: 'isBuiltInAlgorithmJob'
           property :is_hyperparameter_tuning_job, as: 'isHyperparameterTuningJob'
           collection :trials, as: 'trials', class: Google::Apis::MlV1::GoogleCloudMlV1HyperparameterOutput, decorator: Google::Apis::MlV1::GoogleCloudMlV1HyperparameterOutput::Representation

generated/google/apis/storagetransfer_v1.rb

@@ -26,7 +26,7 @@ module Google
     # @see https://cloud.google.com/storage-transfer/docs
     module StoragetransferV1
       VERSION = 'V1'
-      REVISION = '20190513'
+      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/storagetransfer_v1/classes.rb

@@ -392,9 +392,10 @@ module Google
         # If specified, only objects with a `lastModificationTime` on or after
         # `NOW` - `maxTimeElapsedSinceLastModification` and objects that don't have
         # a `lastModificationTime` are transferred.
-        # Note that `NOW` refers to the creation time of the transfer job, and
+        # Note that, for each `TransferOperation` started by this `TransferJob`,
+        # `NOW` refers to the `start_time` of the 'TransferOperation`. Also,
         # `lastModificationTime` refers to the time of the last change to the
-        # object's content or metadata. Specifically, this would be the `updated`
+        # object's content or metadata - specifically, this would be the `updated`
         # property of GCS objects and the `LastModified` field of S3 objects.
         # Corresponds to the JSON property `maxTimeElapsedSinceLastModification`
         # @return [String]
@@ -403,9 +404,10 @@ module Google
         # If specified, only objects with a `lastModificationTime` before
         # `NOW` - `minTimeElapsedSinceLastModification` and objects that don't have a
         # `lastModificationTime` are transferred.
-        # Note that `NOW` refers to the creation time of the transfer job, and
+        # Note that, for each `TransferOperation` started by this `TransferJob`,
+        # `NOW` refers to the `start_time` of the 'TransferOperation`. Also,
         # `lastModificationTime` refers to the time of the last change to the
-        # object's content or metadata. Specifically, this would be the `updated`
+        # object's content or metadata - specifically, this would be the `updated`
         # property of GCS objects and the `LastModified` field of S3 objects.
         # Corresponds to the JSON property `minTimeElapsedSinceLastModification`
         # @return [String]
@@ -439,43 +441,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::StoragetransferV1::Status]
         attr_accessor :error
@@ -593,43 +562,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/youtube_partner_v1.rb

@@ -18,14 +18,14 @@ require 'google/apis/youtube_partner_v1/representations.rb'
 
 module Google
   module Apis
-    # Youtube Content ID API
+    # YouTube Content ID API
     #
     # API for YouTube partners. To use this API a YouTube CMS account is required.
     #
     # @see https://developers.google.com/youtube/partner/
     module YoutubePartnerV1
       VERSION = 'V1'
-      REVISION = '20190502'
+      REVISION = '20190603'
 
       # View and manage your assets and associated content on YouTube
       AUTH_YOUTUBEPARTNER = 'https://www.googleapis.com/auth/youtubepartner'

generated/google/apis/youtube_partner_v1/service.rb

@@ -20,7 +20,7 @@ require 'google/apis/errors'
 module Google
   module Apis
     module YoutubePartnerV1
-      # Youtube Content ID API
+      # YouTube Content ID API
       #
       # API for YouTube partners. To use this API a YouTube CMS account is required.
       #