Doc fixes (#10624)

Co-authored-by: Nadine Spies <[email protected]>
Co-authored-by: Art Berger <[email protected]>
Co-authored-by: changelog-bot <changelog-bot>

Author: 3 people

changelog/v1.19.0-beta10/docs-ai-gw.yaml

@@ -0,0 +1,5 @@
+changelog:
+  - type: NON_USER_FACING
+    resolvesIssue: true
+    description: >-
+      Weekly doc fixes and minor updates.

docs/content/guides/security/access_logging/_index.md

@@ -411,14 +411,14 @@ You can apply different filters on your access logs to reduce and optimize the n
 
 ### Using status code filters
 
-You can apply access log filters to requests that match a specific HTTP status code by using the `defaultValue` or `runtimeKey` option. 
+You can apply access log filters to requests that match a specific HTTP status code by using the `defaultValue` and `runtimeKey` option. 
 
 **Option 1: Use `defaultValue`** </br>
 
 Use the `defaultValue` option in the Gateway resource to specify the HTTP status code for which you want to apply the access log filter. Note that the `defaultValue` is set for a specific Gateway only. To apply the same HTTP status code to multiple Gateway resources, see `Option 2: Override the default value with a runtime key-value pair`. 
 
 1. Follow the steps in [File-based](#file-based-access-logging) or [gRPC](#grpc-access-logging) access logging to enable access logging for your gateway.
-2. To apply additional filters to your access logs, you create or edit your gateway resource and add the access log filters to the `spec.options.accessLoggingService.accessLog` section. The following example uses file-based access logging and captures access logs only for requests with an HTTP response code that is greater than or equal to 400. 
+2. To apply additional filters to your access logs, you create or edit your gateway resource and add the access log filters to the `spec.options.accessLoggingService.accessLog` section. The following example uses file-based access logging and captures access logs only for requests with an HTTP response code that is greater than or equal to 400. Note that the `runtimeKey` overrides any settings in `defaultValue`, so in this example, the `runtimeKey` is also set to 400.
    ```yaml
    apiVersion: gateway.solo.io/v1
    kind: Gateway
@@ -445,6 +445,7 @@ Use the `defaultValue` option in the Gateway resource to specify the HTTP status
                  op: GE
                  value: 
                    defaultValue: 400
+                   runtimeKey: "400"
      proxyNames:
      - gateway-proxy
      ssl: false
@@ -467,7 +468,7 @@ Note that the `runtimeKey` is enforced only if it matches a key that is defined
 3. Create or edit your gateway resource and add the access log filters to the `spec.options.accessLoggingService.accessLog` section. The following example uses file-based access logging and captures access logs only for requests with an HTTP response code that is greater than or equal to what is defined in the `access_log_status_filter` runtime value.
 
    {{% notice note %}}
-   Note that the `runtimeKey` overrides any settings in `defaultValue`
+   Note that the `runtimeKey` overrides any settings in `defaultValue`.
    {{% /notice %}}
 
    ```yaml

docs/content/guides/traffic_management/request_processing/upstream_health_checks/_index.md

@@ -4,20 +4,21 @@ weight: 50
 description: Automatically monitor the status of Upstreams by configuring health checks for them
 ---
 
-As part of configuring an Upstream, Gloo Gateway provides the option of adding *health checks* that periodically assess the readiness of the Upstream to receive requests. See the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/v1.14.1/intro/arch_overview/upstream/health_checking#arch-overview-health-checking) for more information. 
+As part of configuring an Upstream, Gloo Gateway provides the option of adding *health checks* that periodically assess the readiness of the Upstream to receive requests. For more information, see the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/v1.14.1/intro/arch_overview/upstream/health_checking#arch-overview-health-checking). 
 
 {{% notice note %}}
-Upstreams with working health checks will not be removed from Envoy's service directory, even due to configuration changes. To allow them to be removed, set `ignoreHealthOnHostRemoval` in the Upstream's configuration.
+Upstreams with working health checks are not removed from Envoy's service directory, even due to configuration changes. To allow removal in such cases, set `ignoreHealthOnHostRemoval` in the Upstream's configuration.
 {{% /notice %}}
+
 ## Configuration
 
-Descriptions of the options available for configuring health checks can be found {{< protobuf name="solo.io.envoy.api.v2.core.HealthCheck" display="here" >}}.
+Review the following sections for example configuration settings of common use cases. For descriptions of each field, refer to the [API documentation]({{% versioned_link_path fromRoot="/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/options/healthcheck/healthcheck.proto.sk/" %}}).
 
 ### Custom paths for HttpHealthChecks
 
-There is a way to add custom paths to health check requests shown in the example below.
+To add custom paths to health check requests, review the following example.
 
-{{< highlight yaml >}}
+```yaml
 spec:
   healthChecks:
   - healthyThreshold: 1
@@ -26,6 +27,12 @@ spec:
     interval: 30s
     timeout: 10s
     unhealthyThreshold: 1
-{{< /highlight >}}
+```
 
-A `path` represents an explicitly-specified path to check the health of the upstream. The `timeout` declares how much time between checks there should be. An `unhealthyThreshold` is the limit of checks that are allowed to fail before declaring the upstream unhealthy. A `healthyThreshold` is the limit of checks that are allowed to pass before declaring an upstream healthy. The `interval` is the interval of time that you send `healthchecks` as to not overload your upstream service. 
+| Setting | Description |
+| --- | --- |
+| `path` | The specific path to send the health check request to the upstream. Make sure that the backing destination handles health checks along this path. |
+| `timeout` | The amount of time that the health check waits for a response before considering the request unsuccessful and timing out. | 
+| `unhealthyThreshold` | The number of checks that can fail before the upstream is considered unhealthy. The example allows only one failed health check. |
+| `healthyThreshold` | The number of checks that must succeed before an upstream is considered healthy. The example requires only one successful health check.
+| `interval` | How often the health check sends requests. Set a value that will not overload your upstream service. |

docs/content/operations/production_deployment/_index.md

@@ -214,7 +214,7 @@ global:
     extAuth:
       signingKey:
         name: extauth-signing-key
-        signing-key: <signing-key-value>
+        key: <signing-key-value>
 ```
 
 #### Pod Disruption Budgets and Affinity/Anti-Affinity rules

docs/content/reference/api/_index.md

@@ -19,7 +19,7 @@ Gloo Edge is a high-performance, plugin-extendable, platform-agnostic API Gatewa
 Gateway
 - Gateway: {{< protobuf name="gateway.solo.io.Gateway" >}}
 - HTTPGateway: {{< protobuf name="gateway.solo.io.HttpGateway" >}}
-- HTTPListenerOptions: {{< protobuf name="gloo.solo.io.HTTPListenerOptions" >}}
+- HTTPListenerOptions: {{< protobuf name="gloo.solo.io.HttpListenerOptions" >}}
 - ListenerOptions: {{< protobuf name="gloo.solo.io.ListenerOptions" >}}
 - TCPGateway: {{< protobuf name="gateway.solo.io.TcpGateway" >}}