Autogenerated update (2019-06-09)
Update: - redis_v1 - redis_v1beta1
This commit is contained in:
parent
af83fb6f94
commit
14eda05425
|
@ -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'
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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'
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue