| <html><body> |
| <style> |
| |
| body, h1, h2, h3, div, span, p, pre, a { |
| margin: 0; |
| padding: 0; |
| border: 0; |
| font-weight: inherit; |
| font-style: inherit; |
| font-size: 100%; |
| font-family: inherit; |
| vertical-align: baseline; |
| } |
| |
| body { |
| font-size: 13px; |
| padding: 1em; |
| } |
| |
| h1 { |
| font-size: 26px; |
| margin-bottom: 1em; |
| } |
| |
| h2 { |
| font-size: 24px; |
| margin-bottom: 1em; |
| } |
| |
| h3 { |
| font-size: 20px; |
| margin-bottom: 1em; |
| margin-top: 1em; |
| } |
| |
| pre, code { |
| line-height: 1.5; |
| font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace; |
| } |
| |
| pre { |
| margin-top: 0.5em; |
| } |
| |
| h1, h2, h3, p { |
| font-family: Arial, sans serif; |
| } |
| |
| h1, h2, h3 { |
| border-bottom: solid #CCC 1px; |
| } |
| |
| .toc_element { |
| margin-top: 0.5em; |
| } |
| |
| .firstline { |
| margin-left: 2 em; |
| } |
| |
| .method { |
| margin-top: 1em; |
| border: solid 1px #CCC; |
| padding: 1em; |
| background: #EEE; |
| } |
| |
| .details { |
| font-weight: bold; |
| font-size: 14px; |
| } |
| |
| </style> |
| |
| <h1><a href="runtimeconfig_v1beta1.html">Google Cloud RuntimeConfig 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=None, body, x__xgafv=None)</a></code></p> |
| <p class="firstline">Creates a Waiter resource. This operation returns a long-running Operation</p> |
| <p class="toc_element"> |
| <code><a href="#delete">delete(name, x__xgafv=None)</a></code></p> |
| <p class="firstline">Deletes the Waiter with the specified name.</p> |
| <p class="toc_element"> |
| <code><a href="#get">get(name, x__xgafv=None)</a></code></p> |
| <p class="firstline">Gets the Waiter resource with the specified name.</p> |
| <p class="toc_element"> |
| <code><a href="#list">list(parent=None, pageToken=None, x__xgafv=None, pageSize=None)</a></code></p> |
| <p class="firstline">List Waiters within the given RuntimeConfig resource.</p> |
| <p class="toc_element"> |
| <code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p> |
| <p class="firstline">Retrieves the next page of results.</p> |
| <h3>Method Details</h3> |
| <div class="method"> |
| <code class="details" id="create">create(parent=None, body, x__xgafv=None)</code> |
| <pre>Creates a Waiter resource. This operation returns a long-running Operation |
| resource which can be polled for completion. However, a Waiter with the |
| given name will exist (and can be retrieved) prior to the resultant |
| Operation completing. If the resultant Operation indicates a failure, the |
| failed Waiter resource will still exist and must be deleted prior to |
| subsequent creation attempts. |
| |
| Args: |
| parent: string, The fully-qualified name of the configuration that will own the waiter. |
| Required. Must be a valid configuration name. (required) |
| body: object, The request body. (required) |
| The object takes the form of: |
| |
| { # A Waiter resource waits for some condition within a RuntimeConfig resource |
| # to be met. For example: each node in a distributed system startup process |
| # writes a value to a Variable resource indicating its readiness. A Waiter |
| # configured with the proper `success` condition can be used to wait until |
| # some number of nodes have checked in. |
| # Once created, a Waiter resource is immutable. |
| "name": "A String", # Name of the variable resource. |
| # It has format of |
| # "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}", |
| # Where `project_id` must be a valid Google Cloud project ID, `config_id` |
| # must be a valid RuntimeConfig object and the `waiter_id` must match |
| # RFC 1035 segment specification, and `len(waiter_id)` must be less than |
| # 64 bytes. |
| # The name is assigned by the client, but will be validated on the server |
| # side to adhere to the format. |
| # Name is immutable and cannot be changed. Required. |
| "success": { # A condition that a Waiter resource is waiting for. The set of possible # 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. Required. |
| # conditions may expand over time. |
| "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration. |
| # under the specified path prefix reaches the specified number. |
| # For example, take the following variables in a RuntimeConfig object: |
| # /foo/variable1 = "value1" |
| # /foo/variable2 = "value2" |
| # /bar/variable3 = "value3" |
| # |
| # These variables would satisfy a Cardinality condition with `path` set to |
| # "/foo" and `number` set to 2, but would not satisify the same condition |
| # with `number` set to 3. |
| "path": "A String", # The root of the variable subtree to monitor. Required. |
| "number": 42, # The number of decendents of `path` that must exist before this condition |
| # is met. Optional; defaults to 1 if not specified. |
| }, |
| }, |
| "failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to |
| # `true` and the `error` code will be set to ABORTED. The failure condition |
| # takes precedence over the success condition. If both conditions are met, a |
| # failure will be indicated. This value is optional; if no failure condition |
| # is set, the only failure scenario will be a timeout. Optional. |
| # conditions may expand over time. |
| "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration. |
| # under the specified path prefix reaches the specified number. |
| # For example, take the following variables in a RuntimeConfig object: |
| # /foo/variable1 = "value1" |
| # /foo/variable2 = "value2" |
| # /bar/variable3 = "value3" |
| # |
| # These variables would satisfy a Cardinality condition with `path` set to |
| # "/foo" and `number` set to 2, but would not satisify the same condition |
| # with `number` set to 3. |
| "path": "A String", # The root of the variable subtree to monitor. Required. |
| "number": 42, # The number of decendents of `path` that must exist before this condition |
| # is met. Optional; defaults to 1 if not specified. |
| }, |
| }, |
| "done": True or False, # 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 |
| # or failure, `error` will be set. Output only. |
| "timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If |
| # this timeout elapses prior to the success or failure conditions being met, |
| # the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED. |
| # Required. |
| "error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set. |
| # Output only. |
| # 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` which 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 purpose. |
| # |
| # - 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. |
| "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. |
| { |
| "a_key": "", # Properties of the object. Contains field @ype with type URL. |
| }, |
| ], |
| }, |
| "createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout` |
| # to this instant yields the timeout deadline for this Waiter. Output only. |
| } |
| |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # 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 @ype 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 |
| # `Get`/`Create`/`Update`, the response should be the resource. For other |
| # methods, the response should have the type `XxxResponse`, where `Xxx` |
| # is the original method name. For example, if the original method name |
| # is `TakeSnapshot()`, the inferred response type is |
| # `TakeSnapshotResponse`. |
| "a_key": "", # Properties of the object. Contains field @ype with type URL. |
| }, |
| "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. |
| # 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` which 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 purpose. |
| # |
| # - 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. |
| "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. |
| { |
| "a_key": "", # Properties of the object. Contains field @ype with type URL. |
| }, |
| ], |
| }, |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="delete">delete(name, x__xgafv=None)</code> |
| <pre>Deletes the Waiter with the specified name. |
| |
| Args: |
| name: string, The Waiter resource to delete. (required) |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # A generic empty message that you can re-use to avoid defining duplicated |
| # empty messages in your APIs. A typical example is to use it as the request |
| # or the response type of an API method. For instance: |
| # |
| # service Foo { |
| # rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); |
| # } |
| # |
| # The JSON representation for `Empty` is empty JSON object `{}`. |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="get">get(name, x__xgafv=None)</code> |
| <pre>Gets the Waiter resource with the specified name. |
| |
| Args: |
| name: string, The fully-qualified name of the Waiter resource object to retrieve. (required) |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # A Waiter resource waits for some condition within a RuntimeConfig resource |
| # to be met. For example: each node in a distributed system startup process |
| # writes a value to a Variable resource indicating its readiness. A Waiter |
| # configured with the proper `success` condition can be used to wait until |
| # some number of nodes have checked in. |
| # Once created, a Waiter resource is immutable. |
| "name": "A String", # Name of the variable resource. |
| # It has format of |
| # "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}", |
| # Where `project_id` must be a valid Google Cloud project ID, `config_id` |
| # must be a valid RuntimeConfig object and the `waiter_id` must match |
| # RFC 1035 segment specification, and `len(waiter_id)` must be less than |
| # 64 bytes. |
| # The name is assigned by the client, but will be validated on the server |
| # side to adhere to the format. |
| # Name is immutable and cannot be changed. Required. |
| "success": { # A condition that a Waiter resource is waiting for. The set of possible # 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. Required. |
| # conditions may expand over time. |
| "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration. |
| # under the specified path prefix reaches the specified number. |
| # For example, take the following variables in a RuntimeConfig object: |
| # /foo/variable1 = "value1" |
| # /foo/variable2 = "value2" |
| # /bar/variable3 = "value3" |
| # |
| # These variables would satisfy a Cardinality condition with `path` set to |
| # "/foo" and `number` set to 2, but would not satisify the same condition |
| # with `number` set to 3. |
| "path": "A String", # The root of the variable subtree to monitor. Required. |
| "number": 42, # The number of decendents of `path` that must exist before this condition |
| # is met. Optional; defaults to 1 if not specified. |
| }, |
| }, |
| "failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to |
| # `true` and the `error` code will be set to ABORTED. The failure condition |
| # takes precedence over the success condition. If both conditions are met, a |
| # failure will be indicated. This value is optional; if no failure condition |
| # is set, the only failure scenario will be a timeout. Optional. |
| # conditions may expand over time. |
| "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration. |
| # under the specified path prefix reaches the specified number. |
| # For example, take the following variables in a RuntimeConfig object: |
| # /foo/variable1 = "value1" |
| # /foo/variable2 = "value2" |
| # /bar/variable3 = "value3" |
| # |
| # These variables would satisfy a Cardinality condition with `path` set to |
| # "/foo" and `number` set to 2, but would not satisify the same condition |
| # with `number` set to 3. |
| "path": "A String", # The root of the variable subtree to monitor. Required. |
| "number": 42, # The number of decendents of `path` that must exist before this condition |
| # is met. Optional; defaults to 1 if not specified. |
| }, |
| }, |
| "done": True or False, # 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 |
| # or failure, `error` will be set. Output only. |
| "timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If |
| # this timeout elapses prior to the success or failure conditions being met, |
| # the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED. |
| # Required. |
| "error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set. |
| # Output only. |
| # 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` which 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 purpose. |
| # |
| # - 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. |
| "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. |
| { |
| "a_key": "", # Properties of the object. Contains field @ype with type URL. |
| }, |
| ], |
| }, |
| "createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout` |
| # to this instant yields the timeout deadline for this Waiter. Output only. |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="list">list(parent=None, pageToken=None, x__xgafv=None, pageSize=None)</code> |
| <pre>List Waiters within the given RuntimeConfig resource. |
| |
| Args: |
| parent: string, The fully-qualified name of the configuration to list. |
| Required. Must be a valid configuration name. (required) |
| pageToken: string, The token for pagination. |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| pageSize: integer, List pagination support. |
| The size of the page to return. We may return fewer elements. |
| |
| Returns: |
| An object of the form: |
| |
| { # Response for the `ListWaiters()` method. |
| # Order of returned waiter objects is arbitrary. |
| "nextPageToken": "A String", # Pagination support. |
| "waiters": [ # Found waiters in the project. |
| { # A Waiter resource waits for some condition within a RuntimeConfig resource |
| # to be met. For example: each node in a distributed system startup process |
| # writes a value to a Variable resource indicating its readiness. A Waiter |
| # configured with the proper `success` condition can be used to wait until |
| # some number of nodes have checked in. |
| # Once created, a Waiter resource is immutable. |
| "name": "A String", # Name of the variable resource. |
| # It has format of |
| # "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}", |
| # Where `project_id` must be a valid Google Cloud project ID, `config_id` |
| # must be a valid RuntimeConfig object and the `waiter_id` must match |
| # RFC 1035 segment specification, and `len(waiter_id)` must be less than |
| # 64 bytes. |
| # The name is assigned by the client, but will be validated on the server |
| # side to adhere to the format. |
| # Name is immutable and cannot be changed. Required. |
| "success": { # A condition that a Waiter resource is waiting for. The set of possible # 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. Required. |
| # conditions may expand over time. |
| "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration. |
| # under the specified path prefix reaches the specified number. |
| # For example, take the following variables in a RuntimeConfig object: |
| # /foo/variable1 = "value1" |
| # /foo/variable2 = "value2" |
| # /bar/variable3 = "value3" |
| # |
| # These variables would satisfy a Cardinality condition with `path` set to |
| # "/foo" and `number` set to 2, but would not satisify the same condition |
| # with `number` set to 3. |
| "path": "A String", # The root of the variable subtree to monitor. Required. |
| "number": 42, # The number of decendents of `path` that must exist before this condition |
| # is met. Optional; defaults to 1 if not specified. |
| }, |
| }, |
| "failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to |
| # `true` and the `error` code will be set to ABORTED. The failure condition |
| # takes precedence over the success condition. If both conditions are met, a |
| # failure will be indicated. This value is optional; if no failure condition |
| # is set, the only failure scenario will be a timeout. Optional. |
| # conditions may expand over time. |
| "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration. |
| # under the specified path prefix reaches the specified number. |
| # For example, take the following variables in a RuntimeConfig object: |
| # /foo/variable1 = "value1" |
| # /foo/variable2 = "value2" |
| # /bar/variable3 = "value3" |
| # |
| # These variables would satisfy a Cardinality condition with `path` set to |
| # "/foo" and `number` set to 2, but would not satisify the same condition |
| # with `number` set to 3. |
| "path": "A String", # The root of the variable subtree to monitor. Required. |
| "number": 42, # The number of decendents of `path` that must exist before this condition |
| # is met. Optional; defaults to 1 if not specified. |
| }, |
| }, |
| "done": True or False, # 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 |
| # or failure, `error` will be set. Output only. |
| "timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If |
| # this timeout elapses prior to the success or failure conditions being met, |
| # the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED. |
| # Required. |
| "error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set. |
| # Output only. |
| # 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` which 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 purpose. |
| # |
| # - 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. |
| "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. |
| { |
| "a_key": "", # Properties of the object. Contains field @ype with type URL. |
| }, |
| ], |
| }, |
| "createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout` |
| # to this instant yields the timeout deadline for this Waiter. Output only. |
| }, |
| ], |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="list_next">list_next(previous_request, previous_response)</code> |
| <pre>Retrieves the next page of results. |
| |
| Args: |
| previous_request: The request for the previous page. (required) |
| previous_response: The response from the request for the previous page. (required) |
| |
| Returns: |
| A request object that you can call 'execute()' on to request the next |
| page. Returns None if there are no more items in the collection. |
| </pre> |
| </div> |
| |
| </body></html> |
