Regen all docs. (#700)

* Stop recursing if discovery == {}

* Generate docs with 'make docs'.
diff --git a/docs/dyn/ml_v1.projects.operations.html b/docs/dyn/ml_v1.projects.operations.html
index c86e30f..b576dcf 100644
--- a/docs/dyn/ml_v1.projects.operations.html
+++ b/docs/dyn/ml_v1.projects.operations.html
@@ -72,19 +72,16 @@
 
 </style>
 
-<h1><a href="ml_v1.html">Google Cloud Machine Learning Engine</a> . <a href="ml_v1.projects.html">projects</a> . <a href="ml_v1.projects.operations.html">operations</a></h1>
+<h1><a href="ml_v1.html">Cloud Machine Learning Engine</a> . <a href="ml_v1.projects.html">projects</a> . <a href="ml_v1.projects.operations.html">operations</a></h1>
 <h2>Instance Methods</h2>
 <p class="toc_element">
   <code><a href="#cancel">cancel(name, x__xgafv=None)</a></code></p>
 <p class="firstline">Starts asynchronous cancellation on a long-running operation.  The server</p>
 <p class="toc_element">
-  <code><a href="#delete">delete(name, x__xgafv=None)</a></code></p>
-<p class="firstline">Deletes a long-running operation. This method indicates that the client is</p>
-<p class="toc_element">
   <code><a href="#get">get(name, x__xgafv=None)</a></code></p>
 <p class="firstline">Gets the latest state of a long-running operation.  Clients can use this</p>
 <p class="toc_element">
-  <code><a href="#list">list(name, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</a></code></p>
+  <code><a href="#list">list(name, pageToken=None, x__xgafv=None, pageSize=None, filter=None)</a></code></p>
 <p class="firstline">Lists operations that match the specified filter in the request. If the</p>
 <p class="toc_element">
   <code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p>
@@ -126,35 +123,6 @@
 </div>
 
 <div class="method">
-    <code class="details" id="delete">delete(name, x__xgafv=None)</code>
-  <pre>Deletes a long-running operation. This method indicates that the client is
-no longer interested in the operation result. It does not cancel the
-operation. If the server doesn't support this method, it returns
-`google.rpc.Code.UNIMPLEMENTED`.
-
-Args:
-  name: string, The name of the operation resource to be deleted. (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 latest state of a long-running operation.  Clients can use this
 method to poll the operation result at intervals as recommended by the API
@@ -178,71 +146,26 @@
         # long-running operation should document the metadata type, if any.
       "a_key": "", # Properties of the object. Contains field @type with type URL.
     },
-    "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:
+    "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.
         },
       ],
     },
     "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
+        # 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
@@ -256,12 +179,12 @@
     },
     "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`.
+        # `name` should be a resource name ending with `operations/{unique_id}`.
   }</pre>
 </div>
 
 <div class="method">
-    <code class="details" id="list">list(name, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</code>
+    <code class="details" id="list">list(name, pageToken=None, x__xgafv=None, pageSize=None, filter=None)</code>
   <pre>Lists operations that match the specified filter in the request. If the
 server doesn't support this method, it returns `UNIMPLEMENTED`.
 
@@ -275,19 +198,18 @@
 
 Args:
   name: string, The name of the operation's parent resource. (required)
-  pageSize: integer, The standard list page size.
-  filter: string, The standard list filter.
   pageToken: string, The standard list page token.
   x__xgafv: string, V1 error format.
     Allowed values
       1 - v1 error format
       2 - v2 error format
+  pageSize: integer, The standard list page size.
+  filter: string, The standard list filter.
 
 Returns:
   An object of the form:
 
     { # The response message for Operations.ListOperations.
-    "nextPageToken": "A String", # The standard List next-page token.
     "operations": [ # A list of operations that matches the specified filter in the request.
       { # This resource represents a long-running operation that is the result of a
           # network API call.
@@ -297,71 +219,26 @@
             # long-running operation should document the metadata type, if any.
           "a_key": "", # Properties of the object. Contains field @type with type URL.
         },
-        "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:
+        "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.
             },
           ],
         },
         "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
+            # 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
@@ -375,9 +252,10 @@
         },
         "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`.
+            # `name` should be a resource name ending with `operations/{unique_id}`.
       },
     ],
+    "nextPageToken": "A String", # The standard List next-page token.
   }</pre>
 </div>