feat(networkservices): update the api

#### networkservices:v1

The following keys were added:
- schemas.ListGatewaysResponse.properties.unreachable (Total Keys: 2)

#### networkservices:v1beta1

The following keys were added:
- schemas.ListGatewaysResponse.properties.unreachable (Total Keys: 2)

docs/dyn/networkservices_v1.projects.locations.gateways.html

@@ -344,6 +344,9 @@ <h3>Method Details</h3>
     },
   ],
   &quot;nextPageToken&quot;: &quot;A String&quot;, # If there might be more results than those appearing in this response, then `next_page_token` is included. To get the next set of results, call this method again using the value of `next_page_token` as `page_token`.
+  &quot;unreachable&quot;: [ # Locations that could not be reached.
+    &quot;A String&quot;,
+  ],
 }</pre>
 </div>
 

docs/dyn/networkservices_v1.projects.locations.grpcRoutes.html

@@ -116,7 +116,7 @@ <h3>Method Details</h3>
   &quot;gateways&quot;: [ # Optional. Gateways defines a list of gateways this GrpcRoute is attached to, as one of the routing rules to route the requests served by the gateway. Each gateway reference should match the pattern: `projects/*/locations/global/gateways/`
     &quot;A String&quot;,
   ],
-  &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. &quot;foo.example.com&quot;) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. *.example.com). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames &quot;*.foo.bar.com&quot; and &quot;*.bar.com&quot; to be associated with the same route, it is not possible to associate two routes both with &quot;*.bar.com&quot; or both with &quot;bar.com&quot;. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
+  &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (`*.`). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. `foo.example.com`) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. `*.example.com`). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames `*.foo.bar.com` and `*.bar.com` to be associated with the same route, it is not possible to associate two routes both with `*.bar.com` or both with `bar.com`. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
     &quot;A String&quot;,
   ],
   &quot;labels&quot;: { # Optional. Set of label tags associated with the GrpcRoute resource.
@@ -261,7 +261,7 @@ <h3>Method Details</h3>
   &quot;gateways&quot;: [ # Optional. Gateways defines a list of gateways this GrpcRoute is attached to, as one of the routing rules to route the requests served by the gateway. Each gateway reference should match the pattern: `projects/*/locations/global/gateways/`
     &quot;A String&quot;,
   ],
-  &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. &quot;foo.example.com&quot;) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. *.example.com). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames &quot;*.foo.bar.com&quot; and &quot;*.bar.com&quot; to be associated with the same route, it is not possible to associate two routes both with &quot;*.bar.com&quot; or both with &quot;bar.com&quot;. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
+  &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (`*.`). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. `foo.example.com`) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. `*.example.com`). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames `*.foo.bar.com` and `*.bar.com` to be associated with the same route, it is not possible to associate two routes both with `*.bar.com` or both with `bar.com`. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
     &quot;A String&quot;,
   ],
   &quot;labels&quot;: { # Optional. Set of label tags associated with the GrpcRoute resource.
@@ -346,7 +346,7 @@ <h3>Method Details</h3>
       &quot;gateways&quot;: [ # Optional. Gateways defines a list of gateways this GrpcRoute is attached to, as one of the routing rules to route the requests served by the gateway. Each gateway reference should match the pattern: `projects/*/locations/global/gateways/`
         &quot;A String&quot;,
       ],
-      &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. &quot;foo.example.com&quot;) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. *.example.com). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames &quot;*.foo.bar.com&quot; and &quot;*.bar.com&quot; to be associated with the same route, it is not possible to associate two routes both with &quot;*.bar.com&quot; or both with &quot;bar.com&quot;. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
+      &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (`*.`). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. `foo.example.com`) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. `*.example.com`). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames `*.foo.bar.com` and `*.bar.com` to be associated with the same route, it is not possible to associate two routes both with `*.bar.com` or both with `bar.com`. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
         &quot;A String&quot;,
       ],
       &quot;labels&quot;: { # Optional. Set of label tags associated with the GrpcRoute resource.
@@ -439,7 +439,7 @@ <h3>Method Details</h3>
   &quot;gateways&quot;: [ # Optional. Gateways defines a list of gateways this GrpcRoute is attached to, as one of the routing rules to route the requests served by the gateway. Each gateway reference should match the pattern: `projects/*/locations/global/gateways/`
     &quot;A String&quot;,
   ],
-  &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. &quot;foo.example.com&quot;) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. *.example.com). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames &quot;*.foo.bar.com&quot; and &quot;*.bar.com&quot; to be associated with the same route, it is not possible to associate two routes both with &quot;*.bar.com&quot; or both with &quot;bar.com&quot;. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
+  &quot;hostnames&quot;: [ # Required. Service hostnames with an optional port for which this route describes traffic. Format: [:] Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: - IPs are not allowed. - A hostname may be prefixed with a wildcard label (`*.`). The wildcard label must appear by itself as the first label. Hostname can be &quot;precise&quot; which is a domain name without the terminating dot of a network host (e.g. `foo.example.com`) or &quot;wildcard&quot;, which is a domain name prefixed with a single wildcard label (e.g. `*.example.com`). Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or &#x27;-&#x27;, and must start and end with an alphanumeric character. No other punctuation is allowed. The routes associated with a Mesh or Gateway must have unique hostnames. If you attempt to attach multiple routes with conflicting hostnames, the configuration will be rejected. For example, while it is acceptable for routes for the hostnames `*.foo.bar.com` and `*.bar.com` to be associated with the same route, it is not possible to associate two routes both with `*.bar.com` or both with `bar.com`. If a port is specified, then gRPC clients must use the channel URI with the port to match this rule (i.e. &quot;xds:///service:123&quot;), otherwise they must supply the URI without a port (i.e. &quot;xds:///service&quot;).
     &quot;A String&quot;,
   ],
   &quot;labels&quot;: { # Optional. Set of label tags associated with the GrpcRoute resource.

docs/dyn/networkservices_v1.projects.locations.html

@@ -166,7 +166,7 @@ <h3>Method Details</h3>
 Returns:
   An object of the form:
 
-    { # A resource that represents Google Cloud Platform location.
+    { # A resource that represents a Google Cloud location.
   &quot;displayName&quot;: &quot;A String&quot;, # The friendly name for this location, typically a nearby city name. For example, &quot;Tokyo&quot;.
   &quot;labels&quot;: { # Cross-service attributes for the location. For example {&quot;cloud.googleapis.com/region&quot;: &quot;us-east1&quot;}
     &quot;a_key&quot;: &quot;A String&quot;,
@@ -198,7 +198,7 @@ <h3>Method Details</h3>
 
     { # The response message for Locations.ListLocations.
   &quot;locations&quot;: [ # A list of locations that matches the specified filter in the request.
-    { # A resource that represents Google Cloud Platform location.
+    { # A resource that represents a Google Cloud location.
       &quot;displayName&quot;: &quot;A String&quot;, # The friendly name for this location, typically a nearby city name. For example, &quot;Tokyo&quot;.
       &quot;labels&quot;: { # Cross-service attributes for the location. For example {&quot;cloud.googleapis.com/region&quot;: &quot;us-east1&quot;}
         &quot;a_key&quot;: &quot;A String&quot;,