diff --git a/generated/google/apis/redis_v1.rb b/generated/google/apis/redis_v1.rb index a253e62d4..b135f53bf 100644 --- a/generated/google/apis/redis_v1.rb +++ b/generated/google/apis/redis_v1.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/memorystore/docs/redis/ module RedisV1 VERSION = 'V1' - REVISION = '20190531' + REVISION = '20190607' # 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/redis_v1/classes.rb b/generated/google/apis/redis_v1/classes.rb index ac41ea295..946eba9b5 100644 --- a/generated/google/apis/redis_v1/classes.rb +++ b/generated/google/apis/redis_v1/classes.rb @@ -80,7 +80,7 @@ module Google end end - # The GCS location for the output content + # The Cloud Storage location for the output content class GcsDestination include Google::Apis::Core::Hashable @@ -100,7 +100,7 @@ module Google end end - # The GCS location for the input content + # The Cloud Storage location for the input content class GcsSource include Google::Apis::Core::Hashable @@ -237,7 +237,7 @@ module Google class InputConfig include Google::Apis::Core::Hashable - # The GCS location for the input content + # The Cloud Storage location for the input content # Corresponds to the JSON property `gcsSource` # @return [Google::Apis::RedisV1::GcsSource] attr_accessor :gcs_source @@ -563,43 +563,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::RedisV1::Status] attr_accessor :error @@ -657,7 +624,7 @@ module Google class OutputConfig include Google::Apis::Core::Hashable - # The GCS location for the output content + # The Cloud Storage location for the output content # Corresponds to the JSON property `gcsDestination` # @return [Google::Apis::RedisV1::GcsDestination] attr_accessor :gcs_destination @@ -674,43 +641,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/redis_v1/service.rb b/generated/google/apis/redis_v1/service.rb index 5830689b6..64edc51bd 100644 --- a/generated/google/apis/redis_v1/service.rb +++ b/generated/google/apis/redis_v1/service.rb @@ -201,7 +201,7 @@ module Google execute_or_queue_command(command, &block) end - # Export Redis instance data into a Redis RDB format file in GCS. + # Export Redis instance data into a Redis RDB format file in Cloud Storage. # Redis will continue serving during this operation. # The returned operation is automatically deleted after a few hours, so # there is no need to call DeleteOperation. @@ -307,7 +307,7 @@ module Google execute_or_queue_command(command, &block) end - # Import a Redis RDB snapshot file from GCS into a Redis instance. + # Import a Redis RDB snapshot file from Cloud Storage into a Redis instance. # Redis may stop serving during this operation. Instance state will be # IMPORTING for entire operation. When complete, the instance will contain # only data from the imported file. diff --git a/generated/google/apis/redis_v1beta1.rb b/generated/google/apis/redis_v1beta1.rb index e5cab0bcc..a74715013 100644 --- a/generated/google/apis/redis_v1beta1.rb +++ b/generated/google/apis/redis_v1beta1.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/memorystore/docs/redis/ module RedisV1beta1 VERSION = 'V1beta1' - REVISION = '20190531' + REVISION = '20190607' # 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/redis_v1beta1/classes.rb b/generated/google/apis/redis_v1beta1/classes.rb index 7dbaeb8ef..2c89d0e96 100644 --- a/generated/google/apis/redis_v1beta1/classes.rb +++ b/generated/google/apis/redis_v1beta1/classes.rb @@ -60,7 +60,7 @@ module Google end end - # The GCS location for the output content + # The Cloud Storage location for the output content class GcsDestination include Google::Apis::Core::Hashable @@ -80,7 +80,7 @@ module Google end end - # The GCS location for the input content + # The Cloud Storage location for the input content class GcsSource include Google::Apis::Core::Hashable @@ -220,7 +220,7 @@ module Google class InputConfig include Google::Apis::Core::Hashable - # The GCS location for the input content + # The Cloud Storage location for the input content # Corresponds to the JSON property `gcsSource` # @return [Google::Apis::RedisV1beta1::GcsSource] attr_accessor :gcs_source @@ -553,43 +553,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::RedisV1beta1::Status] attr_accessor :error @@ -647,7 +614,7 @@ module Google class OutputConfig include Google::Apis::Core::Hashable - # The GCS location for the output content + # The Cloud Storage location for the output content # Corresponds to the JSON property `gcsDestination` # @return [Google::Apis::RedisV1beta1::GcsDestination] attr_accessor :gcs_destination @@ -664,43 +631,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/redis_v1beta1/service.rb b/generated/google/apis/redis_v1beta1/service.rb index 9eab43e6a..35c9d05eb 100644 --- a/generated/google/apis/redis_v1beta1/service.rb +++ b/generated/google/apis/redis_v1beta1/service.rb @@ -201,7 +201,7 @@ module Google execute_or_queue_command(command, &block) end - # Export Redis instance data into a Redis RDB format file in GCS. + # Export Redis instance data into a Redis RDB format file in Cloud Storage. # Redis will continue serving during this operation. # The returned operation is automatically deleted after a few hours, so # there is no need to call DeleteOperation. @@ -271,7 +271,7 @@ module Google execute_or_queue_command(command, &block) end - # Import a Redis RDB snapshot file from GCS into a Redis instance. + # Import a Redis RDB snapshot file from Cloud Storage into a Redis instance. # Redis may stop serving during this operation. Instance state will be # IMPORTING for entire operation. When complete, the instance will contain # only data from the imported file.