diff --git a/generated/google/apis/appengine_v1.rb b/generated/google/apis/appengine_v1.rb index a181f8a93..cc47d1044 100644 --- a/generated/google/apis/appengine_v1.rb +++ b/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' diff --git a/generated/google/apis/appengine_v1/classes.rb b/generated/google/apis/appengine_v1/classes.rb index 6bd31a235..6174ffc38 100644 --- a/generated/google/apis/appengine_v1/classes.rb +++ b/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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/appengine_v1alpha.rb b/generated/google/apis/appengine_v1alpha.rb index 1b77d4fe4..286a8ea27 100644 --- a/generated/google/apis/appengine_v1alpha.rb +++ b/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' diff --git a/generated/google/apis/appengine_v1alpha/classes.rb b/generated/google/apis/appengine_v1alpha/classes.rb index c06755fce..c700d2e64 100644 --- a/generated/google/apis/appengine_v1alpha/classes.rb +++ b/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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/appengine_v1beta.rb b/generated/google/apis/appengine_v1beta.rb index 59f950204..a14be30bd 100644 --- a/generated/google/apis/appengine_v1beta.rb +++ b/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' diff --git a/generated/google/apis/appengine_v1beta/classes.rb b/generated/google/apis/appengine_v1beta/classes.rb index ac3479f5c..328c13660 100644 --- a/generated/google/apis/appengine_v1beta/classes.rb +++ b/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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/cloudtasks_v2beta2.rb b/generated/google/apis/cloudtasks_v2beta2.rb index 1be4dbc07..bd3e470bd 100644 --- a/generated/google/apis/cloudtasks_v2beta2.rb +++ b/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' diff --git a/generated/google/apis/cloudtasks_v2beta2/classes.rb b/generated/google/apis/cloudtasks_v2beta2/classes.rb index f4e2dadb5..628f0f8e3 100644 --- a/generated/google/apis/cloudtasks_v2beta2/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/container_v1beta1.rb b/generated/google/apis/container_v1beta1.rb index f1153fb68..5b92a6b13 100644 --- a/generated/google/apis/container_v1beta1.rb +++ b/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' diff --git a/generated/google/apis/container_v1beta1/classes.rb b/generated/google/apis/container_v1beta1/classes.rb index 80477925a..bf041104e 100644 --- a/generated/google/apis/container_v1beta1/classes.rb +++ b/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. diff --git a/generated/google/apis/genomics_v1.rb b/generated/google/apis/genomics_v1.rb index a33a9fe53..e779868b7 100644 --- a/generated/google/apis/genomics_v1.rb +++ b/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' diff --git a/generated/google/apis/genomics_v1/classes.rb b/generated/google/apis/genomics_v1/classes.rb index d36364b44..e9e4a9461 100644 --- a/generated/google/apis/genomics_v1/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/genomics_v1alpha2.rb b/generated/google/apis/genomics_v1alpha2.rb index 3d7a1ea4f..9aedad603 100644 --- a/generated/google/apis/genomics_v1alpha2.rb +++ b/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' diff --git a/generated/google/apis/genomics_v1alpha2/classes.rb b/generated/google/apis/genomics_v1alpha2/classes.rb index 3c361b6dc..30af6c826 100644 --- a/generated/google/apis/genomics_v1alpha2/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/genomics_v2alpha1.rb b/generated/google/apis/genomics_v2alpha1.rb index 5fd48ba8a..c4083e50d 100644 --- a/generated/google/apis/genomics_v2alpha1.rb +++ b/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' diff --git a/generated/google/apis/genomics_v2alpha1/classes.rb b/generated/google/apis/genomics_v2alpha1/classes.rb index 76da0008a..bbd90f5a4 100644 --- a/generated/google/apis/genomics_v2alpha1/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/monitoring_v3.rb b/generated/google/apis/monitoring_v3.rb index 1b083eeee..a041921f3 100644 --- a/generated/google/apis/monitoring_v3.rb +++ b/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' diff --git a/generated/google/apis/monitoring_v3/classes.rb b/generated/google/apis/monitoring_v3/classes.rb index 025f1b24e..4cdcbe00e 100644 --- a/generated/google/apis/monitoring_v3/classes.rb +++ b/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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # Simple to use and understand for most users - # Flexible enough to meet unexpected needsOverviewThe Status message contains - # three pieces of data: error code, error message, and error details. The error - # code should be an enum value of google.rpc.Code, but it may accept additional - # error codes if needed. The error message should be a developer-facing English - # message that helps developers understand and resolve the error. If a localized - # user-facing error message is needed, put the localized message in the error - # details or localize it in the client. The optional error details may contain - # arbitrary information about the error. There is a predefined set of error - # detail types in the package google.rpc that can be used for common error - # conditions.Language mappingThe Status message is the logical representation of - # the error model, but it is not necessarily the actual wire format. When the - # Status message is exposed in different client libraries and different wire - # protocols, it can be mapped differently. For example, it will likely be mapped - # to some exceptions in Java, but more likely mapped to some error codes in C. - # Other usesThe error model and the Status message can be used in a variety of - # environments, either with or without APIs, to provide a consistent developer - # experience across different environments.Example uses of this error model - # include: - # Partial errors. If a service needs to return partial errors to the client, it - # may embed the Status in the normal response to indicate the partial errors. - # Workflow errors. A typical workflow has multiple steps. Each step may have a - # Status message for error reporting. - # Batch operations. If a client uses batch request and batch response, the - # Status message should be used directly inside batch response, one for each - # error sub-response. - # Asynchronous operations. If an API call embeds asynchronous operation results - # in its response, the status of those operations should be represented directly - # using the Status message. - # Logging. If some API errors are stored in logs, the message Status could be - # used directly after any stripping needed for security/privacy reasons. + # (https://github.com/grpc). Each Status message contains three pieces of data: + # error code, error message, and error details.You can find out more about this + # error model and how to work with it in the API Design Guide (https://cloud. + # google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/monitoring_v3/service.rb b/generated/google/apis/monitoring_v3/service.rb index 0aff2bcf0..1c8096bdf 100644 --- a/generated/google/apis/monitoring_v3/service.rb +++ b/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' diff --git a/generated/google/apis/remotebuildexecution_v1.rb b/generated/google/apis/remotebuildexecution_v1.rb index 0bab48694..b556cbc66 100644 --- a/generated/google/apis/remotebuildexecution_v1.rb +++ b/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' diff --git a/generated/google/apis/remotebuildexecution_v1/classes.rb b/generated/google/apis/remotebuildexecution_v1/classes.rb index f29f3902b..8ada66471 100644 --- a/generated/google/apis/remotebuildexecution_v1/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class GoogleRpcStatus include Google::Apis::Core::Hashable diff --git a/generated/google/apis/remotebuildexecution_v1alpha.rb b/generated/google/apis/remotebuildexecution_v1alpha.rb index d521a0649..df9da9997 100644 --- a/generated/google/apis/remotebuildexecution_v1alpha.rb +++ b/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' diff --git a/generated/google/apis/remotebuildexecution_v1alpha/classes.rb b/generated/google/apis/remotebuildexecution_v1alpha/classes.rb index 72bcdc6a0..ac6d35828 100644 --- a/generated/google/apis/remotebuildexecution_v1alpha/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class GoogleRpcStatus include Google::Apis::Core::Hashable diff --git a/generated/google/apis/remotebuildexecution_v2.rb b/generated/google/apis/remotebuildexecution_v2.rb index 1d1d24a1f..0806d9702 100644 --- a/generated/google/apis/remotebuildexecution_v2.rb +++ b/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' diff --git a/generated/google/apis/remotebuildexecution_v2/classes.rb b/generated/google/apis/remotebuildexecution_v2/classes.rb index a4a75bb20..0805c19fd 100644 --- a/generated/google/apis/remotebuildexecution_v2/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class GoogleRpcStatus include Google::Apis::Core::Hashable diff --git a/generated/google/apis/runtimeconfig_v1.rb b/generated/google/apis/runtimeconfig_v1.rb index 593a6bc13..e635ca28c 100644 --- a/generated/google/apis/runtimeconfig_v1.rb +++ b/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' diff --git a/generated/google/apis/runtimeconfig_v1/classes.rb b/generated/google/apis/runtimeconfig_v1/classes.rb index f9bc3e2df..ece1fcb41 100644 --- a/generated/google/apis/runtimeconfig_v1/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/runtimeconfig_v1beta1.rb b/generated/google/apis/runtimeconfig_v1beta1.rb index df0315822..591b093d8 100644 --- a/generated/google/apis/runtimeconfig_v1beta1.rb +++ b/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' diff --git a/generated/google/apis/runtimeconfig_v1beta1/classes.rb b/generated/google/apis/runtimeconfig_v1beta1/classes.rb index d74ef067c..998f6e9ba 100644 --- a/generated/google/apis/runtimeconfig_v1beta1/classes.rb +++ b/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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable @@ -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: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::RuntimeconfigV1beta1::Status] attr_accessor :error diff --git a/generated/google/apis/serviceconsumermanagement_v1.rb b/generated/google/apis/serviceconsumermanagement_v1.rb index 19e35442f..2b2792a1f 100644 --- a/generated/google/apis/serviceconsumermanagement_v1.rb +++ b/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' diff --git a/generated/google/apis/serviceconsumermanagement_v1/classes.rb b/generated/google/apis/serviceconsumermanagement_v1/classes.rb index c7fa0c3d7..80e1ac86e 100644 --- a/generated/google/apis/serviceconsumermanagement_v1/classes.rb +++ b/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 diff --git a/generated/google/apis/servicenetworking_v1.rb b/generated/google/apis/servicenetworking_v1.rb index b67b32f85..7e1a1b727 100644 --- a/generated/google/apis/servicenetworking_v1.rb +++ b/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' diff --git a/generated/google/apis/servicenetworking_v1/classes.rb b/generated/google/apis/servicenetworking_v1/classes.rb index 05135c3be..80d9f8bc7 100644 --- a/generated/google/apis/servicenetworking_v1/classes.rb +++ b/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 diff --git a/generated/google/apis/servicenetworking_v1beta.rb b/generated/google/apis/servicenetworking_v1beta.rb index 418a1e155..5d448dad5 100644 --- a/generated/google/apis/servicenetworking_v1beta.rb +++ b/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' diff --git a/generated/google/apis/servicenetworking_v1beta/classes.rb b/generated/google/apis/servicenetworking_v1beta/classes.rb index 4854eea2f..8ab05fb58 100644 --- a/generated/google/apis/servicenetworking_v1beta/classes.rb +++ b/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 diff --git a/generated/google/apis/serviceusage_v1.rb b/generated/google/apis/serviceusage_v1.rb index 672addad1..e4328e9f7 100644 --- a/generated/google/apis/serviceusage_v1.rb +++ b/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' diff --git a/generated/google/apis/serviceusage_v1/classes.rb b/generated/google/apis/serviceusage_v1/classes.rb index ef1ebd5a8..dbf387949 100644 --- a/generated/google/apis/serviceusage_v1/classes.rb +++ b/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 diff --git a/generated/google/apis/serviceusage_v1beta1.rb b/generated/google/apis/serviceusage_v1beta1.rb index 7da97ec7f..dafc01fec 100644 --- a/generated/google/apis/serviceusage_v1beta1.rb +++ b/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' diff --git a/generated/google/apis/serviceusage_v1beta1/classes.rb b/generated/google/apis/serviceusage_v1beta1/classes.rb index 1711b11e9..23d969330 100644 --- a/generated/google/apis/serviceusage_v1beta1/classes.rb +++ b/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 diff --git a/generated/google/apis/storage_v1.rb b/generated/google/apis/storage_v1.rb index b6fc7b370..c318dffa7 100644 --- a/generated/google/apis/storage_v1.rb +++ b/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' diff --git a/generated/google/apis/storage_v1/classes.rb b/generated/google/apis/storage_v1/classes.rb index de402aa84..d441c660b 100644 --- a/generated/google/apis/storage_v1/classes.rb +++ b/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 diff --git a/generated/google/apis/storage_v1/representations.rb b/generated/google/apis/storage_v1/representations.rb index 9b26c2fcd..788809d30 100644 --- a/generated/google/apis/storage_v1/representations.rb +++ b/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