kgateway-dev · soloio-bulldozer · Aug 12, 2024 · Aug 12, 2024
diff --git a/changelog/v1.14.32/docs-backport.yaml b/changelog/v1.14.32/docs-backport.yaml
@@ -0,0 +1,5 @@
+changelog:
+  - type: NON_USER_FACING
+    description: >- 
+      Weekly doc fixes such as links, grammar, typos, and version updates.
+      skipCI-kube-tests:true
diff --git a/docs/content/guides/observability/tracing/envoy.md b/docs/content/guides/observability/tracing/envoy.md
@@ -201,10 +201,10 @@ Add the Envoy code that you want to apply to a Kubernetes configmap and restart
 
 ### Step 3. Configure Zipkin as the tracing provider for a listener {#provider}
 
-After you configure the [tracing cluster](#cluster), you can now set Zipkin as the tracing platform for a listener in your Gloo Edge gateway. To do that, you can either update the Gloo Edge gateway, or provide the Envoy code in a Kubernetes configmap and apply this configmap by manually restarting the Envoy proxies.
+After you configure the [tracing cluster](#cluster), you can now set Zipkin as the tracing platform for a listener in your gateway. To do that, you can either update the gateway or provide the Envoy code in a Kubernetes configmap. Then, apply this configmap by manually restarting the Envoy proxies.
 
 {{% notice note %}}
-When you choose to manually update the Envoy proxies with a configmap, you can apply the updated configuration to a static listener that is defined in the Envoy bootstrap config only. If you want to configure a tracing provider for dynamically created listeners, you must update the gateway in Gloo Edge. 
+When you choose to manually update the Envoy proxies with a configmap, you can apply the updated configuration to a static listener that is defined in the Envoy bootstrap config only. If you want to configure a tracing provider for dynamically created listeners, you must update the gateway. 
 {{% /notice %}}
 
 **Option 1: Dynamic listeners with Gloo Edge**

diff --git a/docs/content/guides/security/auth/extauth/apikey_auth/_index.md b/docs/content/guides/security/auth/extauth/apikey_auth/_index.md
@@ -67,7 +67,7 @@ Now let's configure Gloo Edge to route requests to the upstream we just created.
 {{< /tab >}}
 {{< /tabs >}} 
 
-Let's send a request that matches the above route to the Gloo Edge gateway and make sure it works:
+Let's send a request that matches the above route to the gateway proxy and make sure it works:
 
 ```shell
 curl -H "Host: foo" $(glooctl proxy url)/posts/1

diff --git a/docs/content/guides/security/auth/extauth/basic_auth/_index.md b/docs/content/guides/security/auth/extauth/basic_auth/_index.md
@@ -46,7 +46,7 @@ Service to match all requests that:
 Apply the following virtual service:
 {{< readfile file="guides/security/auth/extauth/basic_auth/test-no-auth-vs.yaml" markdown="true">}}
 
-Let's send a request that matches the above route to the Gloo Edge gateway and make sure it works:
+Let's send a request that matches the above route to the gateway proxy and make sure it works:
 
 ```shell
 curl -H "Host: foo" $(glooctl proxy url)/posts/1

diff --git a/docs/content/guides/security/auth/extauth/oauth/auth0/_index.md b/docs/content/guides/security/auth/extauth/oauth/auth0/_index.md
@@ -303,7 +303,7 @@ After this callback, the normal request flow continues and the upstream `httpbin
 
 ![GlooTest Response](./auth0-glootest-get-1.png)
 
-You can also test other `httpbin` endpoints via the Gloo Edge gateway.  For example, consider this base64 conversion service endpoint:  https://glootest.com/base64/R2xvbyBpcyBhd2Vzb21lCg==
+You can also test other `httpbin` endpoints via the gateway.  For example, consider this base64 conversion service endpoint:  https://glootest.com/base64/R2xvbyBpcyBhd2Vzb21lCg==
 
 ![GlooTest Base64 Conversion](./httpbin-base64.png)
 

diff --git a/docs/content/guides/security/auth/extauth/oauth/okta/_index.md b/docs/content/guides/security/auth/extauth/oauth/okta/_index.md
@@ -354,7 +354,7 @@ After this callback, the normal request flow continues and the upstream applicat
 
 ![GlooTest Response]({{% versioned_link_path fromRoot="/img/glootest-get-1.png" %}})
 
-You can also test other `httpbin` endpoints via the Gloo Edge gateway.  For example, consider this base64 conversion service endpoint:  https://glootest.com/base64/R2xvbyBpcyBhd2Vzb21lCg==
+You can also test other `httpbin` endpoints via the gateway.  For example, consider this base64 conversion service endpoint:  https://glootest.com/base64/R2xvbyBpcyBhd2Vzb21lCg==
 
 ![GlooTest Base64 Conversion]({{% versioned_link_path fromRoot="/img/httpbin-base64.png" %}})
 

diff --git a/docs/content/guides/security/auth/extauth/passthrough_auth/grpc/_index.md b/docs/content/guides/security/auth/extauth/passthrough_auth/grpc/_index.md
@@ -87,7 +87,7 @@ Service to match all requests that:
 Apply the following virtual service:
 {{< readfile file="guides/security/auth/extauth/basic_auth/test-no-auth-vs.yaml" markdown="true">}}
 
-Let's send a request that matches the above route to the Gloo Edge gateway and make sure it works:
+Let's send a request that matches the above route to the gateway proxy and make sure it works:
 
 ```shell
 curl -H "Host: foo" $(glooctl proxy url)/posts/1

diff --git a/docs/content/guides/security/auth/extauth/passthrough_auth/http/_index.md b/docs/content/guides/security/auth/extauth/passthrough_auth/http/_index.md
@@ -82,7 +82,7 @@ Service to match all requests that:
 Apply the following virtual service:
 {{< readfile file="guides/security/auth/extauth/basic_auth/test-no-auth-vs.yaml" markdown="true">}}
 
-Let's send a request that matches the above route to the Gloo Edge gateway and make sure it works:
+Let's send a request that matches the above route to the gateway proxy and make sure it works:
 
 ```shell
 curl -H "Host: foo" $(glooctl proxy url)/posts/1

diff --git a/docs/content/guides/traffic_management/destination_types/grpc/grpc-transcoding.md b/docs/content/guides/traffic_management/destination_types/grpc/grpc-transcoding.md
@@ -154,11 +154,6 @@ status:
       ```
       kubectl apply -f upstream.yaml
       ```
-
-{{% notice note %}}
-Adding the proto descriptor binary to the upstream is the recommended gRPC transcoding practice. However, you can choose to add the proto descriptors to the gateway resource instead of the upstream. For instructions on how to do that, refer to the [Gloo Edge 1.13 docs](https://docs.solo.io/gloo-edge/v1.13.x/guides/traffic_management/destination_types/grpc_to_rest_advanced/). 
-{{% /notice %}}
-
 
 ## Step 4: Set up routing to the gRPC upstream {#grpc-routing}
 

diff --git a/docs/content/installation/gateway/development/docker-compose-consul/_index.md b/docs/content/installation/gateway/development/docker-compose-consul/_index.md
@@ -108,7 +108,7 @@ You can view resources stored in the Consul UI at [http://localhost:8500/ui](htt
 
 You can also view secrets stored in the Vault UI at [http://localhost:8200/ui](http://localhost:8200/ui). Use the `Token` sign-in method, with `root` as the token.
 
-With all the containers now running, it is time to configure the *Upstream* for the Per Store application and a *Virtual Service* on the Gloo Edge gateway to serve content from the Pet Store app.
+With all the containers now running, it is time to configure the *Upstream* for the Pet Store app and a *Virtual Service* on the gateway to serve content from the Pet Store app.
 
 ---
 
@@ -122,7 +122,7 @@ curl --request PUT --data-binary @./install/docker-compose-consul/data/gateways/
 
 ## Configuring Upstream and Virtual Services
 
-The next step is to expose the Pet Store's API through the Gloo Edge gateway. We will do this by creating a service on Consul that Gloo Edge will use as an *Upstream*. Then we will create a *Virtual Service* on Gloo Edge with a routing rule. The configuration data for the *Virtual Service* will be stored in Consul.
+The next step is to expose the Pet Store's API through the gateway. We will do this by creating a service on Consul that Gloo Edge will use as an *Upstream*. Then we will create a *Virtual Service* on Gloo Edge with a routing rule. The configuration data for the *Virtual Service* will be stored in Consul.
 
 To create the service on Consul, we need to get the IP address of the `petstore` container. The command below retrieves the IP address and then creates a JSON file with information about the Pet Store application. The JSON file will be submitted to Consul to create the service.
 

diff --git a/docs/content/introduction/faq.md b/docs/content/introduction/faq.md
@@ -62,7 +62,7 @@ When you install Gloo Edge, you can provide an enterprise license to install Glo
 
 We strive to write good documentation and lots of tutorials in our user guides. If you have a suggestion for how to improve, please tell us! In this section, we'll look at some frequent questions asked when getting started:
 
-### How to change the ports on which Gloo Edge gateway proxy listens?
+### How to change the ports on which the gateway proxy listens?
 
 When considering changing the ports, it's important to understand that the Gloo Edge `gateway-proxy` (Envoy) listens on a port, and when running in Kubernetes, the Kubernetes service maps to a routable service:port as well.
 
@@ -222,7 +222,7 @@ https://192.168.64.50:31767
 
 There will be times when a configuration goes awry or you encounter unexpected behavior. Here are some helpful hints to diagnose these problems.
 
-### How can I see exactly what configuration the Gloo Edge gateway-proxy should see and is seeing?
+### How can I see exactly what configuration the gateway-proxy should see and is seeing?
 
 To show what configuration the `gateway-proxy` *should* see, check the Gloo proxy. Gloo uses the proxy configuration (which also reads in configuration from other Gloo resources such as gateways and virtual services) to translate to an Envoy proxy configuration.
 
@@ -401,7 +401,7 @@ If you want to quickly get the logs for the proxy:
 glooctl proxy logs -f
 ```
 
-### Why are the ports on my Gloo Edge gateway proxy not opened?
+### Why are the ports on my gateway proxy not opened?
 
 For Envoy to open the ports and actually listen, you need to have a Route defined in one of the VirtualServices that will be associated with that particular Gateway/Listener. For example, if have only **one** VirtualService and that has **zero** routes, the corresponding listeners on the `gateway-proxy` will not be active:
 

diff --git a/docs/content/introduction/traffic_filter.md b/docs/content/introduction/traffic_filter.md
@@ -8,7 +8,7 @@ With Gloo Edge, you can configure the gateway listener along with custom Envoy f
 * [Types of request processing](#types-of-request-processing)
 * [Filter flow](#filter-flow)
 
-For an overview of Gloo Edge gateway, virtual service, and upstream configurations, see [Traffic management]({{% versioned_link_path fromRoot="/introduction/traffic_management/" %}}).
+For an overview of gateway, virtual service, and upstream configurations, see [Traffic management]({{% versioned_link_path fromRoot="/introduction/traffic_management/" %}}).
 
 ---
 

diff --git a/docs/content/introduction/traffic_management/_index.md b/docs/content/introduction/traffic_management/_index.md
@@ -25,7 +25,7 @@ Additional information can be found in the [Gloo Edge Core Concepts document]({{
 Let's see what underpins Gloo Edge routing with a high-level look at the layout of the Gloo Edge configuration. This can be seen as 3 layers: the *Gateway listeners*, *Virtual Services*, and *Upstreams*. Mostly, you'll be interacting with [Virtual Services]({{% versioned_link_path fromRoot="/introduction/architecture/concepts#virtual-services" %}}), which allow you to configure the details of the API you wish to expose on the Gateway and how routing happens to the backends. [Upstreams]({{% versioned_link_path fromRoot="/introduction/architecture/concepts#upstreams" %}}) represent those backends. [Gateway]({{% versioned_link_path fromRoot="/introduction/architecture/concepts#gateways" %}}) objects help you control the listeners for incoming traffic.
 
 <figure><img src="{{% versioned_link_path fromRoot="/img/traffic-config-ov.svg" %}}">
-<figcaption style="text-align:center;font-style:italic">Figure: Example configuration of Gloo Edge gateway, virtual service, and upstream resources.</figcaption></figure>
+<figcaption style="text-align:center;font-style:italic">Figure: Example configuration of gateway, virtual service, and upstream resources.</figcaption></figure>
 
 ---
 ## Route Rules

diff --git a/docs/content/reference/support.md b/docs/content/reference/support.md
@@ -12,15 +12,15 @@ Gloo Edge Enterprise offers `n-3` patching support for bug and critical security
 
 | Gloo Edge | Kubernetes | Envoy | Helm | Istio`†` |
 |------|----------|---------|--------|------|
+| 1.17.x | 1.25 - 1.29 | v3 xDS API | >= 3.12 | 1.16 - 1.22 |
 | 1.16.x | 1.24 - 1.28 | v3 xDS API | >= 3.12 | 1.14 - 1.20 |
-| 1.15.x | 1.23 - 1.27 | v3 xDS API | >= 3.8 | 1.13 - 1.17 |
-| 1.14.x | 1.23 - 1.25 | v3 xDS API | >= 3.8 | 1.13 - 1.17 |
-| 1.13.x | 1.21 - 1.24 | v3 xDS API | >= 3.0 | 1.11 - 1.15 |
+| 1.15.x | 1.23 - 1.27 | v3 xDS API | >= 3.11 | 1.13 - 1.18 |
+| 1.14.x | 1.23 - 1.25 | v3 xDS API | >= 3.8 | 1.13 - 1.18 |
 
-{{% notice note %}}`†` **Istio versions**: Gloo Edge is tested on Istio 1.11 - 1.12. Istio must run on a compatible version of Kubernetes. For example, you cannot run Istio 1.15 on Kubernetes 1.21. For more information, see the [Istio docs](https://istio.io/latest/docs/releases/supported-releases/). If you want hardened `n-4` versions of Istio for particular requirements such as FIPS, consider using [Gloo Platform](https://www.solo.io/products/gloo-platform/), which includes Gateway and Mesh components.{{% /notice %}}
+{{% notice note %}}`†` **Istio versions**: Istio must run on a compatible version of Kubernetes. For example, Istio 1.22 is tested, but not supported, on Kubernetes 1.26. For more information, see the [Istio docs](https://istio.io/latest/docs/releases/supported-releases/). If you want hardened `n-4` versions of Istio for particular requirements such as FIPS, consider using [Gloo Mesh Enterprise](https://www.solo.io/products/gloo-mesh/), which includes ingress gateway and service mesh components.{{% /notice %}}
 
 <!--TO FIND VERSIONS
-Go to the branch for the Edge version you want, like 1.11.x. In https://github.com/solo-io/gloo/blob/master/ci/kind/setup-kind.sh, search for CLUSTER_NODE_VERSION to see the max k8s version, and ISTIO_VERSION for max istio version. You will have to ask someone on the team to find out the minimum versions of each for a given Edge release. They do have an [issue](https://github.com/solo-io/gloo/issues/5358) open to run regular tests for min-max though.-->
+For 1.17 and later, go to the version branch, such as v1.17.x. In the .github/workflows.env/nightly-tests directory, open the min_versions.env and max_versions.env files. Example on main: https://github.com/solo-io/gloo/tree/main/.github/workflows/.env/nightly-tests -->
 
 ## Release cadence
 

diff --git a/docs/content/static/content/version_gee_latest.md b/docs/content/static/content/version_gee_latest.md
@@ -1 +1 @@
-1.14.19
+1.14.22
diff --git a/docs/content/static/content/version_gee_n+1.md b/docs/content/static/content/version_gee_n+1.md
@@ -1 +1 @@
-1.15.18
+1.15.21
diff --git a/docs/content/static/content/version_gee_n-1.md b/docs/content/static/content/version_gee_n-1.md
@@ -1 +1 @@
-1.13.34
+1.13.35
diff --git a/docs/content/static/content/version_geoss_latest.md b/docs/content/static/content/version_geoss_latest.md
@@ -1 +1 @@
-1.14.30
+1.14.31
diff --git a/docs/content/static/content/version_geoss_n+1.md b/docs/content/static/content/version_geoss_n+1.md
@@ -1 +1 @@
-1.15.28
+1.15.30
diff --git a/docs/content/static/content/version_geoss_n-1.md b/docs/content/static/content/version_geoss_n-1.md
@@ -1 +1 @@
-1.13.37
+1.13.39