Update docs
diff --git a/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html b/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html
new file mode 100644
index 0000000..0ad5d1f
--- /dev/null
+++ b/docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html
@@ -0,0 +1,685 @@
+<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>
\ No newline at end of file