Regen all docs. (#700)
* Stop recursing if discovery == {}
* Generate docs with 'make docs'.
diff --git a/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html b/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html
index ce42e66..103ba2d 100644
--- a/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html
+++ b/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html
@@ -72,7 +72,7 @@
</style>
-<h1><a href="runtimeconfig_v1beta1.html">Google Cloud Runtime Configuration API</a> . <a href="runtimeconfig_v1beta1.projects.html">projects</a> . <a href="runtimeconfig_v1beta1.projects.configs.html">configs</a> . <a href="runtimeconfig_v1beta1.projects.configs.waiters.html">waiters</a></h1>
+<h1><a href="runtimeconfig_v1beta1.html">Cloud Runtime Configuration API</a> . <a href="runtimeconfig_v1beta1.projects.html">projects</a> . <a href="runtimeconfig_v1beta1.projects.configs.html">configs</a> . <a href="runtimeconfig_v1beta1.projects.configs.waiters.html">waiters</a></h1>
<h2>Instance Methods</h2>
<p class="toc_element">
<code><a href="#create">create(parent, body, requestId=None, x__xgafv=None)</a></code></p>
@@ -103,16 +103,16 @@
Args:
parent: string, The path to the configuration that will own the waiter.
-The configuration must exist beforehand; the path must by in the format:
+The configuration must exist beforehand; the path must be in the format:
`projects/[PROJECT_ID]/configs/[CONFIG_NAME]`. (required)
body: object, The request body. (required)
The object takes the form of:
-{ # A Waiter resource waits for some end condition within a RuntimeConfig resource
- # to be met before it returns. For example, assume you have a distributed
- # system where each node writes to a Variable resource indidicating the node's
- # readiness as part of the startup process.
+{ # A Waiter resource waits for some end condition within a RuntimeConfig
+ # resource to be met before it returns. For example, assume you have a
+ # distributed system where each node writes to a Variable resource indicating
+ # the node's readiness as part of the startup process.
#
# You then configure a Waiter resource with the success condition set to wait
# until some number of nodes have checked in. Afterwards, your application
@@ -122,7 +122,8 @@
# Once created, a Waiter resource is immutable.
#
# To learn more about using waiters, read the
- # [Creating a Waiter](/deployment-manager/runtime-configurator/creating-a-waiter)
+ # [Creating a
+ # Waiter](/deployment-manager/runtime-configurator/creating-a-waiter)
# documentation.
"name": "A String", # The name of the Waiter resource, in the format:
#
@@ -135,21 +136,21 @@
#
# After you create a Waiter resource, you cannot change the resource name.
"success": { # The condition that a Waiter resource is waiting for. # [Required] The success condition. If this condition is met, `done` will be
- # set to `true` and the `error` value will remain unset. The failure condition
- # takes precedence over the success condition. If both conditions are met, a
- # failure will be indicated.
+ # set to `true` and the `error` value will remain unset. The failure
+ # condition takes precedence over the success condition. If both conditions
+ # are met, a failure will be indicated.
"cardinality": { # A Cardinality condition for the Waiter resource. A cardinality condition is # The cardinality of the `EndCondition`.
# met when the number of variables under a specified path prefix reaches a
# predefined number. For example, if you set a Cardinality condition where
- # the `path` is set to `/foo` and the number of paths is set to 2, the
+ # the `path` is set to `/foo` and the number of paths is set to `2`, the
# following variables would meet the condition in a RuntimeConfig resource:
#
# + `/foo/variable1 = "value1"`
# + `/foo/variable2 = "value2"`
# + `/bar/variable3 = "value3"`
#
- # It would not would not satisify the same condition with the `number` set to
- # 3, however, because there is only 2 paths that start with `/foo`.
+ # It would not satisfy the same condition with the `number` set to
+ # `3`, however, because there is only 2 paths that start with `/foo`.
# Cardinality conditions are recursive; all subtrees under the specific
# path prefix are counted.
"path": "A String", # The root of the variable subtree to monitor. For example, `/foo`.
@@ -165,15 +166,15 @@
"cardinality": { # A Cardinality condition for the Waiter resource. A cardinality condition is # The cardinality of the `EndCondition`.
# met when the number of variables under a specified path prefix reaches a
# predefined number. For example, if you set a Cardinality condition where
- # the `path` is set to `/foo` and the number of paths is set to 2, the
+ # the `path` is set to `/foo` and the number of paths is set to `2`, the
# following variables would meet the condition in a RuntimeConfig resource:
#
# + `/foo/variable1 = "value1"`
# + `/foo/variable2 = "value2"`
# + `/bar/variable3 = "value3"`
#
- # It would not would not satisify the same condition with the `number` set to
- # 3, however, because there is only 2 paths that start with `/foo`.
+ # It would not satisfy the same condition with the `number` set to
+ # `3`, however, because there is only 2 paths that start with `/foo`.
# Cardinality conditions are recursive; all subtrees under the specific
# path prefix are counted.
"path": "A String", # The root of the variable subtree to monitor. For example, `/foo`.
@@ -181,7 +182,7 @@
# condition. Defaults to 1 if not specified.
},
},
- "done": True or False, # [Output Only] If the value is `false`, it means the waiter is still waiting
+ "done": True or False, # Output only. If the value is `false`, it means the waiter is still waiting
# for one of its conditions to be met.
#
# If true, the waiter has finished. If the waiter finished due to a timeout
@@ -190,71 +191,26 @@
# the instant that `waiters().create` method is called. If this time elapses
# before the success or failure conditions are met, the waiter fails and sets
# the `error` code to `DEADLINE_EXCEEDED`.
- "error": { # The `Status` type defines a logical error model that is suitable for different # [Output Only] If the waiter ended due to a failure or timeout, this value
+ "error": { # The `Status` type defines a logical error model that is suitable for # Output only. If the waiter ended due to a failure or timeout, this value
# will be set.
- # programming environments, including REST APIs and RPC APIs. It is used by
- # [gRPC](https://github.com/grpc). The error model is designed to be:
+ # different programming environments, including REST APIs and RPC APIs. It is
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - 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.
+ # 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).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
- "details": [ # A list of messages that carry the error details. There will be a
- # common set of message types for APIs to use.
+ "details": [ # A list of messages that carry the error details. There is a common set of
+ # message types for APIs to use.
{
"a_key": "", # Properties of the object. Contains field @type with type URL.
},
],
},
- "createTime": "A String", # [Output Only] The instant at which this Waiter resource was created. Adding
+ "createTime": "A String", # Output only. The instant at which this Waiter resource was created. Adding
# the value of `timeout` to this instant yields the timeout deadline for the
# waiter.
}
@@ -279,15 +235,6 @@
{ # This resource represents a long-running operation that is the result of a
# network API call.
- "metadata": { # Service-specific metadata associated with the operation. It typically
- # contains progress information and common metadata such as create time.
- # Some services might not provide such metadata. Any method that returns a
- # long-running operation should document the metadata type, if any.
- "a_key": "", # Properties of the object. Contains field @type with type URL.
- },
- "done": True or False, # If the value is `false`, it means the operation is still in progress.
- # If true, the operation is completed, and either `error` or `response` is
- # available.
"response": { # The normal response of the operation in case of success. If the original
# method returns no data on success, such as `Delete`, the response is
# `google.protobuf.Empty`. If the original method is standard
@@ -298,67 +245,31 @@
# `TakeSnapshotResponse`.
"a_key": "", # Properties of the object. Contains field @type with type URL.
},
+ "metadata": { # Service-specific metadata associated with the operation. It typically
+ # contains progress information and common metadata such as create time.
+ # Some services might not provide such metadata. Any method that returns a
+ # long-running operation should document the metadata type, if any.
+ "a_key": "", # Properties of the object. Contains field @type with type URL.
+ },
+ "done": True or False, # If the value is `false`, it means the operation is still in progress.
+ # If `true`, the operation is completed, and either `error` or `response` is
+ # available.
"name": "A String", # The server-assigned name, which is only unique within the same service that
# originally returns it. If you use the default HTTP mapping, the
- # `name` should have the format of `operations/some/unique/name`.
- "error": { # The `Status` type defines a logical error model that is suitable for different # The error result of the operation in case of failure or cancellation.
- # programming environments, including REST APIs and RPC APIs. It is used by
- # [gRPC](https://github.com/grpc). The error model is designed to be:
+ # `name` should be a resource name ending with `operations/{unique_id}`.
+ "error": { # The `Status` type defines a logical error model that is suitable for # The error result of the operation in case of failure or cancellation.
+ # different programming environments, including REST APIs and RPC APIs. It is
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - 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.
+ # 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).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
- "details": [ # A list of messages that carry the error details. There will be a
- # common set of message types for APIs to use.
+ "details": [ # A list of messages that carry the error details. There is a common set of
+ # message types for APIs to use.
{
"a_key": "", # Properties of the object. Contains field @type with type URL.
},
@@ -412,10 +323,10 @@
Returns:
An object of the form:
- { # A Waiter resource waits for some end condition within a RuntimeConfig resource
- # to be met before it returns. For example, assume you have a distributed
- # system where each node writes to a Variable resource indidicating the node's
- # readiness as part of the startup process.
+ { # A Waiter resource waits for some end condition within a RuntimeConfig
+ # resource to be met before it returns. For example, assume you have a
+ # distributed system where each node writes to a Variable resource indicating
+ # the node's readiness as part of the startup process.
#
# You then configure a Waiter resource with the success condition set to wait
# until some number of nodes have checked in. Afterwards, your application
@@ -425,7 +336,8 @@
# Once created, a Waiter resource is immutable.
#
# To learn more about using waiters, read the
- # [Creating a Waiter](/deployment-manager/runtime-configurator/creating-a-waiter)
+ # [Creating a
+ # Waiter](/deployment-manager/runtime-configurator/creating-a-waiter)
# documentation.
"name": "A String", # The name of the Waiter resource, in the format:
#
@@ -438,21 +350,21 @@
#
# After you create a Waiter resource, you cannot change the resource name.
"success": { # The condition that a Waiter resource is waiting for. # [Required] The success condition. If this condition is met, `done` will be
- # set to `true` and the `error` value will remain unset. The failure condition
- # takes precedence over the success condition. If both conditions are met, a
- # failure will be indicated.
+ # set to `true` and the `error` value will remain unset. The failure
+ # condition takes precedence over the success condition. If both conditions
+ # are met, a failure will be indicated.
"cardinality": { # A Cardinality condition for the Waiter resource. A cardinality condition is # The cardinality of the `EndCondition`.
# met when the number of variables under a specified path prefix reaches a
# predefined number. For example, if you set a Cardinality condition where
- # the `path` is set to `/foo` and the number of paths is set to 2, the
+ # the `path` is set to `/foo` and the number of paths is set to `2`, the
# following variables would meet the condition in a RuntimeConfig resource:
#
# + `/foo/variable1 = "value1"`
# + `/foo/variable2 = "value2"`
# + `/bar/variable3 = "value3"`
#
- # It would not would not satisify the same condition with the `number` set to
- # 3, however, because there is only 2 paths that start with `/foo`.
+ # It would not satisfy the same condition with the `number` set to
+ # `3`, however, because there is only 2 paths that start with `/foo`.
# Cardinality conditions are recursive; all subtrees under the specific
# path prefix are counted.
"path": "A String", # The root of the variable subtree to monitor. For example, `/foo`.
@@ -468,15 +380,15 @@
"cardinality": { # A Cardinality condition for the Waiter resource. A cardinality condition is # The cardinality of the `EndCondition`.
# met when the number of variables under a specified path prefix reaches a
# predefined number. For example, if you set a Cardinality condition where
- # the `path` is set to `/foo` and the number of paths is set to 2, the
+ # the `path` is set to `/foo` and the number of paths is set to `2`, the
# following variables would meet the condition in a RuntimeConfig resource:
#
# + `/foo/variable1 = "value1"`
# + `/foo/variable2 = "value2"`
# + `/bar/variable3 = "value3"`
#
- # It would not would not satisify the same condition with the `number` set to
- # 3, however, because there is only 2 paths that start with `/foo`.
+ # It would not satisfy the same condition with the `number` set to
+ # `3`, however, because there is only 2 paths that start with `/foo`.
# Cardinality conditions are recursive; all subtrees under the specific
# path prefix are counted.
"path": "A String", # The root of the variable subtree to monitor. For example, `/foo`.
@@ -484,7 +396,7 @@
# condition. Defaults to 1 if not specified.
},
},
- "done": True or False, # [Output Only] If the value is `false`, it means the waiter is still waiting
+ "done": True or False, # Output only. If the value is `false`, it means the waiter is still waiting
# for one of its conditions to be met.
#
# If true, the waiter has finished. If the waiter finished due to a timeout
@@ -493,71 +405,26 @@
# the instant that `waiters().create` method is called. If this time elapses
# before the success or failure conditions are met, the waiter fails and sets
# the `error` code to `DEADLINE_EXCEEDED`.
- "error": { # The `Status` type defines a logical error model that is suitable for different # [Output Only] If the waiter ended due to a failure or timeout, this value
+ "error": { # The `Status` type defines a logical error model that is suitable for # Output only. If the waiter ended due to a failure or timeout, this value
# will be set.
- # programming environments, including REST APIs and RPC APIs. It is used by
- # [gRPC](https://github.com/grpc). The error model is designed to be:
+ # different programming environments, including REST APIs and RPC APIs. It is
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - 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.
+ # 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).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
- "details": [ # A list of messages that carry the error details. There will be a
- # common set of message types for APIs to use.
+ "details": [ # A list of messages that carry the error details. There is a common set of
+ # message types for APIs to use.
{
"a_key": "", # Properties of the object. Contains field @type with type URL.
},
],
},
- "createTime": "A String", # [Output Only] The instant at which this Waiter resource was created. Adding
+ "createTime": "A String", # Output only. The instant at which this Waiter resource was created. Adding
# the value of `timeout` to this instant yields the timeout deadline for the
# waiter.
}</pre>
@@ -569,7 +436,7 @@
Args:
parent: string, The path to the configuration for which you want to get a list of waiters.
-The configuration must exist beforehand; the path must by in the format:
+The configuration must exist beforehand; the path must be in the format:
`projects/[PROJECT_ID]/configs/[CONFIG_NAME]` (required)
pageToken: string, Specifies a page token to use. Set `pageToken` to a `nextPageToken`
@@ -592,10 +459,10 @@
# Subsequent list requests will have their own `nextPageToken` to continue
# paging through the results
"waiters": [ # Found waiters in the project.
- { # A Waiter resource waits for some end condition within a RuntimeConfig resource
- # to be met before it returns. For example, assume you have a distributed
- # system where each node writes to a Variable resource indidicating the node's
- # readiness as part of the startup process.
+ { # A Waiter resource waits for some end condition within a RuntimeConfig
+ # resource to be met before it returns. For example, assume you have a
+ # distributed system where each node writes to a Variable resource indicating
+ # the node's readiness as part of the startup process.
#
# You then configure a Waiter resource with the success condition set to wait
# until some number of nodes have checked in. Afterwards, your application
@@ -605,7 +472,8 @@
# Once created, a Waiter resource is immutable.
#
# To learn more about using waiters, read the
- # [Creating a Waiter](/deployment-manager/runtime-configurator/creating-a-waiter)
+ # [Creating a
+ # Waiter](/deployment-manager/runtime-configurator/creating-a-waiter)
# documentation.
"name": "A String", # The name of the Waiter resource, in the format:
#
@@ -618,21 +486,21 @@
#
# After you create a Waiter resource, you cannot change the resource name.
"success": { # The condition that a Waiter resource is waiting for. # [Required] The success condition. If this condition is met, `done` will be
- # set to `true` and the `error` value will remain unset. The failure condition
- # takes precedence over the success condition. If both conditions are met, a
- # failure will be indicated.
+ # set to `true` and the `error` value will remain unset. The failure
+ # condition takes precedence over the success condition. If both conditions
+ # are met, a failure will be indicated.
"cardinality": { # A Cardinality condition for the Waiter resource. A cardinality condition is # The cardinality of the `EndCondition`.
# met when the number of variables under a specified path prefix reaches a
# predefined number. For example, if you set a Cardinality condition where
- # the `path` is set to `/foo` and the number of paths is set to 2, the
+ # the `path` is set to `/foo` and the number of paths is set to `2`, the
# following variables would meet the condition in a RuntimeConfig resource:
#
# + `/foo/variable1 = "value1"`
# + `/foo/variable2 = "value2"`
# + `/bar/variable3 = "value3"`
#
- # It would not would not satisify the same condition with the `number` set to
- # 3, however, because there is only 2 paths that start with `/foo`.
+ # It would not satisfy the same condition with the `number` set to
+ # `3`, however, because there is only 2 paths that start with `/foo`.
# Cardinality conditions are recursive; all subtrees under the specific
# path prefix are counted.
"path": "A String", # The root of the variable subtree to monitor. For example, `/foo`.
@@ -648,15 +516,15 @@
"cardinality": { # A Cardinality condition for the Waiter resource. A cardinality condition is # The cardinality of the `EndCondition`.
# met when the number of variables under a specified path prefix reaches a
# predefined number. For example, if you set a Cardinality condition where
- # the `path` is set to `/foo` and the number of paths is set to 2, the
+ # the `path` is set to `/foo` and the number of paths is set to `2`, the
# following variables would meet the condition in a RuntimeConfig resource:
#
# + `/foo/variable1 = "value1"`
# + `/foo/variable2 = "value2"`
# + `/bar/variable3 = "value3"`
#
- # It would not would not satisify the same condition with the `number` set to
- # 3, however, because there is only 2 paths that start with `/foo`.
+ # It would not satisfy the same condition with the `number` set to
+ # `3`, however, because there is only 2 paths that start with `/foo`.
# Cardinality conditions are recursive; all subtrees under the specific
# path prefix are counted.
"path": "A String", # The root of the variable subtree to monitor. For example, `/foo`.
@@ -664,7 +532,7 @@
# condition. Defaults to 1 if not specified.
},
},
- "done": True or False, # [Output Only] If the value is `false`, it means the waiter is still waiting
+ "done": True or False, # Output only. If the value is `false`, it means the waiter is still waiting
# for one of its conditions to be met.
#
# If true, the waiter has finished. If the waiter finished due to a timeout
@@ -673,71 +541,26 @@
# the instant that `waiters().create` method is called. If this time elapses
# before the success or failure conditions are met, the waiter fails and sets
# the `error` code to `DEADLINE_EXCEEDED`.
- "error": { # The `Status` type defines a logical error model that is suitable for different # [Output Only] If the waiter ended due to a failure or timeout, this value
+ "error": { # The `Status` type defines a logical error model that is suitable for # Output only. If the waiter ended due to a failure or timeout, this value
# will be set.
- # programming environments, including REST APIs and RPC APIs. It is used by
- # [gRPC](https://github.com/grpc). The error model is designed to be:
+ # different programming environments, including REST APIs and RPC APIs. It is
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - 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.
+ # 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).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
- "details": [ # A list of messages that carry the error details. There will be a
- # common set of message types for APIs to use.
+ "details": [ # A list of messages that carry the error details. There is a common set of
+ # message types for APIs to use.
{
"a_key": "", # Properties of the object. Contains field @type with type URL.
},
],
},
- "createTime": "A String", # [Output Only] The instant at which this Waiter resource was created. Adding
+ "createTime": "A String", # Output only. The instant at which this Waiter resource was created. Adding
# the value of `timeout` to this instant yields the timeout deadline for the
# waiter.
},