gloo-edge or my-gloo-edge to gloo-gateway

docs/content/guides/gloo_federation/federated_configuration.md

@@ -226,7 +226,7 @@ Checking gateways... OK
 Checking proxies... OK
 ```
 
-Note that it is best to have `gloo-edge` installed on this admin cluster. To do so, if needed, you can use the following values and command.
+Note that it is best to have `gloo-gateway` installed on this admin cluster. To do so, if needed, you can use the following values and command.
 ````shell
 cat <<EOF > values-local.yaml
 gloo:

docs/content/guides/integrations/google_cloud/_index.md

@@ -131,7 +131,7 @@ spec:
 # -------------------------------------------------------
   virtualHost:
     domains:
-      - 'my-gloo-edge.com'  # Notice the hostname!!
+      - 'my-gloo-gateway.com'  # Notice the hostname!!
     routes:
       - matchers:
           - prefix: /
@@ -148,7 +148,7 @@ Test that the demo application is reachable. You should see the host name:
 ```bash
 kubectl -n gloo-system port-forward svc/gateway-proxy 8443:443
 
-curl -k -s https://localhost:8443/get -H "Host: my-gloo-edge.com"
+curl -k -s https://localhost:8443/get -H "Host: my-gloo-gateway.com"
 ```
 
 Upgrade your Gloo Gateway installation with the following Helm `values.yaml` file. This example creates 3 replicas for the default gateway proxy and adds specific GCP annotations.
@@ -166,7 +166,7 @@ gloo:
       service:
         type: ClusterIP
         extraAnnotations:
-          cloud.google.com/neg: '{ "exposed_ports":{ "443":{"name": "my-gloo-edge-nlb"} } }'
+          cloud.google.com/neg: '{ "exposed_ports":{ "443":{"name": "my-gloo-gateway-nlb"} } }'
 [...]
 ```
 
@@ -182,7 +182,7 @@ And you will see:
 
 ```text
 NAMESPACE     NAME                                       AGE
-gloo-system   my-gloo-edge-nlb                          1m
+gloo-system   my-gloo-gateway-nlb                          1m
 ```
 
 You can `kubectl describe` the resources to see the status.
@@ -204,7 +204,7 @@ In the diagram you can see the set of resources which are required and you will
 You need to configure a firewall rule to allow to allow communication between the Load Balancer and the pods in the cluster:
 
 ```bash
-gcloud compute firewall-rules create my-gloo-edge-nlb-fw-allow-health-check-and-proxy \
+gcloud compute firewall-rules create my-gloo-gateway-nlb-fw-allow-health-check-and-proxy \
    --action=allow \
    --direction=ingress \
    --source-ranges=0.0.0.0/0 \
@@ -213,7 +213,7 @@ gcloud compute firewall-rules create my-gloo-edge-nlb-fw-allow-health-check-and-
 ```
 
 {{% notice note %}}
-Notice that you are allowing only port `8443` which is the port for gloo-edge https connections.
+Notice that you are allowing only port `8443` which is the port for gloo-gateway https connections.
 {{% /notice %}}
 
 If you did not create custom network tags for your nodes, GKE automatically generates tags for you. You can look up these generated tags by running the following command:
@@ -229,7 +229,7 @@ In the Google Console, you can find the resource at **VPC Network -> Firewall**.
 You need an address for the Load Balancer:
 
 ```bash
-gcloud compute addresses create my-gloo-edge-loadbalancer-address-nlb \
+gcloud compute addresses create my-gloo-gateway-loadbalancer-address-nlb \
     --global
 ```
 
@@ -240,7 +240,7 @@ In the Google Console, you can find the resource at **VPC Network -> External IP
 A health check:
 
 ```bash
-gcloud compute health-checks create tcp my-gloo-edge-nlb-health-check \
+gcloud compute health-checks create tcp my-gloo-gateway-nlb-health-check \
     --global \
     --port 8443 # This is the port for the pod. In the official documentation it might be wrong
 ```
@@ -256,9 +256,9 @@ In the Google Console, you can find the resource at **Compute Engine -> Health c
 A backend service:
 
 ```bash
-gcloud compute backend-services create my-gloo-edge-nlb-backend-service \
+gcloud compute backend-services create my-gloo-gateway-nlb-backend-service \
     --protocol=TCP \
-    --health-checks my-gloo-edge-nlb-health-check \
+    --health-checks my-gloo-gateway-nlb-health-check \
     --global
 ```
 
@@ -269,8 +269,8 @@ In the Google Console, you can find the resource at **Network Services -> Load B
 A target proxy:
 
 ```bash
-gcloud compute target-tcp-proxies create my-gloo-edge-nlb-target-proxy \
-    --backend-service=my-gloo-edge-nlb-backend-service \
+gcloud compute target-tcp-proxies create my-gloo-gateway-nlb-target-proxy \
+    --backend-service=my-gloo-gateway-nlb-backend-service \
     --proxy-header PROXY_V1
 ```
 
@@ -289,10 +289,10 @@ And then the **Target Proxies tab**.
 A forwarding-rule:
 
 ```bash
-gcloud compute forwarding-rules create my-gloo-edge-nlb-content-rule \
-    --address=my-gloo-edge-loadbalancer-address-nlb \
+gcloud compute forwarding-rules create my-gloo-gateway-nlb-content-rule \
+    --address=my-gloo-gateway-loadbalancer-address-nlb \
     --global \
-    --target-tcp-proxy my-gloo-edge-nlb-target-proxy \
+    --target-tcp-proxy my-gloo-gateway-nlb-target-proxy \
     --ports=443
 ```
 
@@ -303,8 +303,8 @@ In the Google Console, you can find the resource as part of the **Advanced Menu*
 And you need to attach the NEG to the backend service:
 
 ```bash
-gcloud compute backend-services add-backend my-gloo-edge-nlb-backend-service \
-    --network-endpoint-group=my-gloo-edge-nlb \
+gcloud compute backend-services add-backend my-gloo-gateway-nlb-backend-service \
+    --network-endpoint-group=my-gloo-gateway-nlb \
     --balancing-mode CONNECTION \
     --max-connections-per-endpoint 5 \
     --network-endpoint-group-zone <my-cluster-zone> \
@@ -320,9 +320,9 @@ After adding the Backend Service to the NEG, you will see the Health Check becom
 Finally, let's test the connectivity through the Load Balancer:
 
 ```bash
-APP_IP=$(gcloud compute addresses describe my-gloo-edge-loadbalancer-address-nlb --global --format=json | jq -r '.address')
+APP_IP=$(gcloud compute addresses describe my-gloo-gateway-loadbalancer-address-nlb --global --format=json | jq -r '.address')
 
-curl -k https://${APP_IP}/get -H "Host: my-gloo-edge.com"
+curl -k https://${APP_IP}/get -H "Host: my-gloo-gateway.com"
 ```
 
 The application should be accessible through the Load Balancer.
@@ -386,7 +386,7 @@ metadata:
 spec:
   virtualHost:
     domains:
-      - 'my-gloo-edge.com'  # Notice the hostname!!
+      - 'my-gloo-gateway.com'  # Notice the hostname!!
     routes:
       - matchers:
           - prefix: /
@@ -403,7 +403,7 @@ Test that the demo application is reachable. You should see the host name:
 ```bash
 kubectl -n gloo-system port-forward svc/gateway-proxy 8080:80
 
-curl -k -s http://localhost:8080/get -H "Host: my-gloo-edge.com"
+curl -k -s http://localhost:8080/get -H "Host: my-gloo-gateway.com"
 ```
 
 Upgrade your Gloo Gateway installation with the following Helm `values.yaml` file. This example creates 3 replicas for the default gateway proxy and adds specific GCP annotations.
@@ -421,7 +421,7 @@ gloo:
       service:
         type: ClusterIP
         extraAnnotations:
-          cloud.google.com/neg: '{ "exposed_ports":{ "80":{"name": "my-gloo-edge-https"} } }'
+          cloud.google.com/neg: '{ "exposed_ports":{ "80":{"name": "my-gloo-gateway-https"} } }'
 [...]
 ```
 
@@ -437,7 +437,7 @@ And you will see:
 
 ```text
 NAMESPACE     NAME                                       AGE
-gloo-system   my-gloo-edge-https                          1m
+gloo-system   my-gloo-gateway-https                          1m
 ```
 
 You can `kubectl describe` the resources to see the status.
@@ -459,7 +459,7 @@ In the diagram you can see the set of resources which are required and you will
 You need to configure a firewall rule to allow to allow communication between the Load Balancer and the pods in the cluster:
 
 ```bash
-gcloud compute firewall-rules create my-gloo-edge-https-fw-allow-health-check-and-proxy \
+gcloud compute firewall-rules create my-gloo-gateway-https-fw-allow-health-check-and-proxy \
    --action=allow \
    --direction=ingress \
    --source-ranges=0.0.0.0/0 \
@@ -468,7 +468,7 @@ gcloud compute firewall-rules create my-gloo-edge-https-fw-allow-health-check-an
 ```
 
 {{% notice note %}}
-Notice that you are allowing only port `8080` which is the port for gloo-edge http connections.
+Notice that you are allowing only port `8080` which is the port for gloo-gateway http connections.
 {{% /notice %}}
 
 If you did not create custom network tags for your nodes, GKE automatically generates tags for you. You can look up these generated tags by running the following command:
@@ -484,7 +484,7 @@ In the Google Console, you can find the resource at **VPC Network -> Firewall**.
 You need an address for the Load Balancer:
 
 ```bash
-gcloud compute addresses create my-gloo-edge-loadbalancer-address-https \
+gcloud compute addresses create my-gloo-gateway-loadbalancer-address-https \
     --global
 ```
 
@@ -495,7 +495,7 @@ In the Google Console, you can find the resource at **VPC Network -> External IP
 A health check:
 
 ```bash
-gcloud compute health-checks create tcp my-gloo-edge-https-health-check \
+gcloud compute health-checks create tcp my-gloo-gateway-https-health-check \
     --global \
     --port 8080 # This is the port for the pod. In the official documentation it might be wrong
 ```
@@ -511,9 +511,9 @@ In the Google Console, you can find the resource at **Compute Engine -> Health c
 A backend service:
 
 ```bash
-gcloud compute backend-services create my-gloo-edge-https-backend-service \
+gcloud compute backend-services create my-gloo-gateway-https-backend-service \
     --protocol=HTTP \
-    --health-checks my-gloo-edge-https-health-check \
+    --health-checks my-gloo-gateway-https-health-check \
     --global
 ```
 
@@ -525,8 +525,8 @@ In the Google Console, you can find the resource at **Network Services -> Load B
 A URL-map:
 
 ```bash
-gcloud compute url-maps create my-gloo-edge-https-url-map \
-    --default-service my-gloo-edge-https-backend-service \
+gcloud compute url-maps create my-gloo-gateway-https-url-map \
+    --default-service my-gloo-gateway-https-backend-service \
     --global
 ```
 
@@ -539,7 +539,7 @@ Create a self-signed certificate and a `ssl-certificate`:
 ```bash
 openssl genrsa -out ca.key 2048
 openssl req -x509 -new -nodes -key ca.key -days 100000 -out ca.crt -subj "/CN=*"
-gcloud compute ssl-certificates create my-gloo-edge-https-certificate \
+gcloud compute ssl-certificates create my-gloo-gateway-https-certificate \
     --certificate=ca.crt \
     --private-key=ca.key \
     --global
@@ -548,9 +548,9 @@ gcloud compute ssl-certificates create my-gloo-edge-https-certificate \
 A target proxy:
 
 ```bash
-gcloud compute target-https-proxies create my-gloo-edge-https-target-proxy \
-    --url-map=my-gloo-edge-https-url-map \
-    --ssl-certificates=my-gloo-edge-https-certificate \
+gcloud compute target-https-proxies create my-gloo-gateway-https-target-proxy \
+    --url-map=my-gloo-gateway-https-url-map \
+    --ssl-certificates=my-gloo-gateway-https-certificate \
     --global
 ```
 
@@ -565,10 +565,10 @@ You can find the resource at **Network Services -> Load Balancing -> Target Prox
 A forwarding-rule:
 
 ```bash
-gcloud compute forwarding-rules create my-gloo-edge-https-content-rule \
-    --address=my-gloo-edge-loadbalancer-address-https \
+gcloud compute forwarding-rules create my-gloo-gateway-https-content-rule \
+    --address=my-gloo-gateway-loadbalancer-address-https \
     --global \
-    --target-https-proxy my-gloo-edge-https-target-proxy \
+    --target-https-proxy my-gloo-gateway-https-target-proxy \
     --ports=443
 ```
 
@@ -579,8 +579,8 @@ In the Google Console, you can find the resource at **Network Services -> Load B
 And you need to attach the NEG to the backend service:
 
 ```bash
-gcloud compute backend-services add-backend my-gloo-edge-https-backend-service \
-    --network-endpoint-group=my-gloo-edge-https \
+gcloud compute backend-services add-backend my-gloo-gateway-https-backend-service \
+    --network-endpoint-group=my-gloo-gateway-https \
     --balancing-mode RATE \
     --max-rate-per-endpoint 5 \
     --network-endpoint-group-zone <my-cluster-zone> \
@@ -592,9 +592,9 @@ Where `<my-cluster-zone>` is the zone where the cluster has been deployed.
 Finally, let's test the connectivity through the Load Balancer:
 
 ```bash
-APP_IP=$(gcloud compute addresses describe my-gloo-edge-loadbalancer-address-https --global --format=json | jq -r '.address')
+APP_IP=$(gcloud compute addresses describe my-gloo-gateway-loadbalancer-address-https --global --format=json | jq -r '.address')
 
-curl -k "https://${APP_IP2}/get" -H "Host: my-gloo-edge.com"
+curl -k "https://${APP_IP2}/get" -H "Host: my-gloo-gateway.com"
 ```
 
 The application should be accessible through the Load Balancer.
@@ -635,9 +635,9 @@ The number of hops is required in order to obtain your own actual client IP.
 2. Try to reach the application through a TLS connection.
 
 ```bash
-APP_IP=$(gcloud compute addresses describe my-gloo-edge-loadbalancer-address-https --global --format=json | jq -r '.address')
+APP_IP=$(gcloud compute addresses describe my-gloo-gateway-loadbalancer-address-https --global --format=json | jq -r '.address')
 
-curl -k "https://${APP_IP2}/get" -H "Host: my-gloo-edge.com"
+curl -k "https://${APP_IP2}/get" -H "Host: my-gloo-gateway.com"
 ```
 
 3. In the response, notice that the `X-Envoy-External-Address` attribute is your own, preserved IP address.

docs/content/guides/integrations/service_mesh/istio.md

@@ -10,7 +10,7 @@ You can configure your Gloo Gateway gateway with an Istio sidecar to secure the
 
 Complete the following tasks before configuring an Istio sidecar for your Gloo Gateway gateway: 
 
-1. Create or use an existing cluster that runs Kubernetes a version supported by both [your version of Edge]({{< versioned_link_path fromRoot="/reference/support" >}}) and the [version of Istio you intend to install](https://istio.io/latest/docs/releases/supported-releases/). 
+1. Create or use an existing cluster that runs Kubernetes a version supported by both [your version ofGloo Gateway]({{< versioned_link_path fromRoot="/reference/support" >}}) and the [version of Istio you intend to install](https://istio.io/latest/docs/releases/supported-releases/). 
 2. [Install Istio in your cluster](https://istio.io/latest/docs/setup/getting-started/). Istio versions 1.13 through 1.17 are supported in Gloo Gateway 1.14. See the [support matrix]({{< versioned_link_path fromRoot="/reference/support" >}}) for more details.
 3. Set up a service mesh for your cluster. For example, you can use [Gloo Mesh Enterprise](https://docs.solo.io/gloo-mesh-enterprise/latest/getting_started/) to configure a service mesh that is based on Envoy and Istio, and that can span across multiple service meshes and clusters. 
 4. Install [Helm version 3](https://helm.sh/docs/intro/install/) on your local machine.

docs/content/guides/observability/tracing/otel.md

@@ -19,7 +19,7 @@ This guide uses the Zipkin tracing platform as an example to show how to set up
 **Before you begin**: Create or update your Gloo Gateway installation to version 1.13.0 or later.
 
 1. Download the [otel-config.yaml](../otel-config.yaml) file, which contains the configmaps, daemonset, deployment, and service for the OTel collector and agents. You can optionally check out the contents to see the OTel collector configuration.
-   * For example, in the `otel-collector-conf` configmap that begins on line 92, the `data.otel-agent-config.receivers` section enables gRPC and HTTP protocols for data collection. The `data.otel-agent-config.exporters` section enables logging data to Zipkin for tracing and to the Edge console for debugging.
+   * For example, in the `otel-collector-conf` configmap that begins on line 92, the `data.otel-agent-config.receivers` section enables gRPC and HTTP protocols for data collection. The `data.otel-agent-config.exporters` section enables logging data to Zipkin for tracing and to theGloo Gateway console for debugging.
    * In the `otel-collector` deployment, you can comment out the ports that begin on line 194 so that only the tracing platform you want to use is enabled, such as Zipkin for this guide.
    * For more information about this configuration, see the [OTel documentation](https://opentelemetry.io/docs/collector/configuration/).
    ```sh

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

@@ -64,7 +64,7 @@ The following steps show an example for Gloo Gateway Enterprise installations. B
    ```
 2. Upgrade or install the Gloo Gateway Enterprise Helm chart with your override settings.
    ```bash
-   helm upgrade --install gloo-edge gloo-ee/gloo-ee --namespace gloo-system --set-string license_key=$YOUR_LICENSE_KEY --version $VERSION -f value-overrides.yaml
+   helm upgrade --install gloo-gateway gloo-ee/gloo-ee --namespace gloo-system --set-string license_key=$YOUR_LICENSE_KEY --version $VERSION -f value-overrides.yaml
    ```
 3. Verify that the `gateway-proxy` deployment mounts the logs volumes.
    ```bash

docs/content/guides/security/auth/extauth/oauth/_index.md

@@ -81,7 +81,7 @@ glooctl create secret oauth --namespace gloo-system --name oidc --client-secret
 {{< /tab >}}
 {{< tab name="kubectl create secret" codelang="shell">}}
 kubectl create secret generic oidc --from-literal=client-secret=<client_secret>
-kubectl annotate secret oidc resource_kind='*v1.Secret' # Important, since gloo-edge does not watch for opaque secrets without this setting
+kubectl annotate secret oidc resource_kind='*v1.Secret' # Important, since gloo-gateway does not watch for opaque secrets without this setting
 {{< /tab >}}
 {{< tab name="kubectl apply" codelang="yaml">}}
 apiVersion: v1

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

@@ -169,9 +169,9 @@ Let's go ahead and describe each one of these attributes in detail.
 By default, `transformationTemplate` parses the request/response body as JSON, depending on whether you configure a `requestTransformation` or `responseTransformation`. If Gloo Gateway fails to parse the request/response body as JSON, it returns a `400 Bad Request` error.
 
 If you want to skip this behavior, you can:
-* Set the [`parseBodyBehavior`](#parsebodybehavior) attribute to `DontParse`. Edge treats the body as plain text and does not parse it.
-* Set the [`ignoreErrorOnParse`](#ignoreerroronparse) attribute to `true`. Edge parses the body as JSON, but does not return an error if the body is not valid JSON.
-* Enable [`passthrough`](#passthrough). Edge does not parse the body.
+* Set the [`parseBodyBehavior`](#parsebodybehavior) attribute to `DontParse`.Gloo Gateway treats the body as plain text and does not parse it.
+* Set the [`ignoreErrorOnParse`](#ignoreerroronparse) attribute to `true`.Gloo Gateway parses the body as JSON, but does not return an error if the body is not valid JSON.
+* Enable [`passthrough`](#passthrough).Gloo Gateway does not parse the body.
 {{% /notice %}}
 ##### parseBodyBehavior
 This attribute determines how the request/response body will be parsed and can have one of two values:

docs/content/installation/advanced_configuration/extauth_custom_ca.md

@@ -46,7 +46,7 @@ helm repo add glooe https://storage.googleapis.com/gloo-ee-helm
 helm repo update
 
 # Create the helm values file (or merge into existing)
-cat > gloo-edge-bring-cert-values.yaml <<EOF
+cat > gloo-gateway-bring-cert-values.yaml <<EOF
 global:
   extensions:
     extAuth:
@@ -69,7 +69,7 @@ Include the `--install` flag to upgrade the existing installation or install a n
 ```bash
 helm upgrade --install gloo glooe/gloo-ee --namespace gloo-system \
   --set-string license_key=LICENSE_KEY \
-  -f gloo-edge-bring-cert-values.yaml
+  -f gloo-gateway-bring-cert-values.yaml
 ```
 
 Once the installation is complete, we can validate our change with the following command: