Merge pull request #7 from ppeble/version-38-fixes

Update AESproductName to Ambassador Edge Stack, productName to Emissary, and OSSproductName to Emissary

Author: ppeble

content/en/docs/3.8/about/changes-2.x.md

@@ -204,7 +204,7 @@ the `AMBASSADOR_ENVOY_API_VERSION` environment variable) will be removed.
 
 ### More Performant Reconfiguration by Default
 
-In Emissary 1.X, the environment variable `AMBASSADOR_FAST_RECONFIGURE` could be used to enable a higher performance implementation of the code Emissary uses to validate and generate Envoy configuration. In $productName$ 2.X, this higher-performance mode is always enabled.
+In Emissary 1.X, the environment variable `AMBASSADOR_FAST_RECONFIGURE` could be used to enable a higher performance implementation of the code Emissary uses to validate and generate Envoy configuration. In Emissary 2.X, this higher-performance mode is always enabled.
 
 ### Changes to the `ambassador` `Module`, and the `tls` `Module`
 

content/en/docs/3.8/about/changes-3.y.md

@@ -2,22 +2,22 @@
 title: Major Changes in Emissary 3.X
 ---
 
-The 3.X family introduces a number of changes to ensure $productName$
+The 3.X family introduces a number of changes to ensure Emissary
 keeps up with latest Envoy versions and to support new features such as HTTP/3.
 We welcome feedback! Join us on [Slack](http://a8r.io/slack) and let us know what you think.
 
-$productName$ 3 is functionally compatible with $productName$ 2.x, but with any major upgrade there are some changes to consider. Such as, Envoy removing support for V2 Transport Protocol features. Below we will outline some of these changes and things to consider when upgrading.
+Emissary 3 is functionally compatible with Emissary 2.x, but with any major upgrade there are some changes to consider. Such as, Envoy removing support for V2 Transport Protocol features. Below we will outline some of these changes and things to consider when upgrading.
 
 ## 1. Envoy Upgraded to 1.22
 
-$productName$ 3.X has been upgraded from Envoy 1.17.X to Envoy **1.22** which keeps $productName$ up-to-date with
+Emissary 3.X has been upgraded from Envoy 1.17.X to Envoy **1.22** which keeps Emissary up-to-date with
 the latest security fixes, bug fixes, performance improvements and feature enhancements provided by Envoy Proxy. Most of the changes are under the hood but the most notable change to developers is the removal of support for Envoy V2 Transport Protocol. This means all AuthServices and LogServices must be updated to use the V3 Protocol.
 
 This also means some of the v2 runtime bootstrap flags have been removed as well:
 
 ```yaml
 # No longer necessary because this was removed from Envoy
-# $productName$ already was converted to use the compressor API
+# Emissary already was converted to use the compressor API
 # https://www.envoyproxy.io/docs/envoy/v1.22.0/configuration/http/http_filters/compressor_filter#config-http-filters-compressor
 "envoy.deprecated_features.allow_deprecated_gzip_http_filter": true,
 
@@ -39,13 +39,13 @@ This also means some of the v2 runtime bootstrap flags have been removed as well
 ## 2. Envoy V2 Protocol Support Removed
 
 With the upgrade to Envoy **1.22**, the V2 Envoy Transport Protocol is no longer supported.
-$productName$ 3.X **only** supports [V3 Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api-v3/api).
+Emissary 3.X **only** supports [V3 Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api-v3/api).
 
 <Alert severity="warn">
 The environment variable <code>AMBASSADOR_ENVOY_API_VERSION</code> has been removed and will no longer have the affect
 of changing the transport protocol.
 </Alert>
 
 <Alert severity="warn">
-The setting of <code>transport_protocol</code> to <code>v2</code> is no longer supported within CRDS (AuthService, etc...). An error will now be logged and $productName$ will not configure envoy correctly. You should remove this field from your CRD's or convert it to <code>v3</code> the only supported version at this time.
+The setting of <code>transport_protocol</code> to <code>v2</code> is no longer supported within CRDS (AuthService, etc...). An error will now be logged and Emissary will not configure envoy correctly. You should remove this field from your CRD's or convert it to <code>v3</code> the only supported version at this time.
 </Alert>

content/en/docs/3.8/about/features-and-benefits.md

@@ -2,44 +2,44 @@
 title: Features and Benefits
 ---
 
-In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. $productName$ was specifically designed for these organizations where developers have operational responsibility for their service(s).
+In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. Emissary was specifically designed for these organizations where developers have operational responsibility for their service(s).
 
-As such, the $productName$ is designed to be used by both developers and operators.
+As such, the Emissary is designed to be used by both developers and operators.
 
 ## Self-Service via Kubernetes Annotations
 
-$productName$ is built from the start to support _self-service_ deployments -- a developer working on a new service doesn't have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes resources or annotations, so they can easily integrate with your existing development workflow.
+Emissary is built from the start to support _self-service_ deployments -- a developer working on a new service doesn't have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes resources or annotations, so they can easily integrate with your existing development workflow.
 
 ## Flexible canary deployments
 
 [//]: # (+FIX+ Forge is no more)
 
-Canary deployments are an essential component of cloud-native development workflows. In a canary deployment, a small percentage of production traffic is routed to a new version of a service to test it under real-world conditions. $productName$ allows developers to easily control and manage the amount of traffic routed to a given service through annotations. [This tutorial](https://www.datawire.io/faster/canary-workflow/) covers a complete canary workflow using the $productName$.
+Canary deployments are an essential component of cloud-native development workflows. In a canary deployment, a small percentage of production traffic is routed to a new version of a service to test it under real-world conditions. Emissary allows developers to easily control and manage the amount of traffic routed to a given service through annotations. [This tutorial](https://www.datawire.io/faster/canary-workflow/) covers a complete canary workflow using the Emissary.
 
 ## Kubernetes-native architecture
 
 [//]: # (+FIX+ we've come to realize that it's better to scale vertically)
 
-$productName$ relies entirely on Kubernetes for reliability, availability, and scalability. For example, $productName$ persists all state in Kubernetes, instead of requiring a separate database. Scaling the $productName$ is as simple as changing the replicas in your deployment, or using a [horizontal pod autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
+Emissary relies entirely on Kubernetes for reliability, availability, and scalability. For example, Emissary persists all state in Kubernetes, instead of requiring a separate database. Scaling the Emissary is as simple as changing the replicas in your deployment, or using a [horizontal pod autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
 
-$productName$ uses [Envoy](https://www.envoyproxy.io) for all traffic routing and proxying. Envoy is a modern L7 proxy that is used in production at companies including Lyft, Apple, Google, and Stripe.
+Emissary uses [Envoy](https://www.envoyproxy.io) for all traffic routing and proxying. Envoy is a modern L7 proxy that is used in production at companies including Lyft, Apple, Google, and Stripe.
 
 ## gRPC and HTTP/2 support
 
-$productName$ fully supports gRPC and HTTP/2 routing, thanks to Envoy's extensive capabilities in this area. See [gRPC and $productName$](../../howtos/grpc) for more information.
+Emissary fully supports gRPC and HTTP/2 routing, thanks to Envoy's extensive capabilities in this area. See [gRPC and Emissary](../../howtos/grpc) for more information.
 
 ## Istio Integration
 
-$productName$ integrates with the [Istio](https://istio.io) service mesh as the edge proxy. In this configuration, $productName$ routes external traffic to the internal Istio service mesh. See [Istio and $productName$](../../howtos/istio) for details.
+Emissary integrates with the [Istio](https://istio.io) service mesh as the edge proxy. In this configuration, Emissary routes external traffic to the internal Istio service mesh. See [Istio and Emissary](../../howtos/istio) for details.
 
 ## Authentication
 
-$productName$ supports authenticating incoming requests using a custom authentication service. When configured, the $productName$ will check with your external authentication service prior to routing an incoming request. For more information, see the [authentication guide](../../topics/running/services/auth-service).
+Emissary supports authenticating incoming requests using a custom authentication service. When configured, the Emissary will check with your external authentication service prior to routing an incoming request. For more information, see the [authentication guide](../../topics/running/services/auth-service).
 
 ## Rate limiting
 
-$productName$ supports rate limiting incoming requests. When configured, the $productName$ will check with a third party rate limit service prior to routing an incoming request. For more information, see the [rate limiting guide](../../topics/using/rate-limits/).
+Emissary supports rate limiting incoming requests. When configured, the Emissary will check with a third party rate limit service prior to routing an incoming request. For more information, see the [rate limiting guide](../../topics/using/rate-limits/).
 
 ## Integrated UI
 
-$productName$ includes a diagnostics service so that you can quickly debug issues associated with configuring the $productName$. For more information, see [running $productName$ in Production](../../topics/running).
+Emissary includes a diagnostics service so that you can quickly debug issues associated with configuring the Emissary. For more information, see [running Emissary in Production](../../topics/running).

content/en/docs/3.8/about/known-issues.md

@@ -5,4 +5,4 @@ title: Known Issues
 ## 2.2.1
 
 - TLS certificates using elliptic curves were incorrectly flagged as invalid. This issue is
-  corrected in $productName$ 2.2.2.
+  corrected in Emissary 2.2.2.

content/en/docs/3.8/about/support.md

@@ -10,15 +10,15 @@ If you need help deploying Emissary at your organization, there are several diff
 
 When running Emissary$ with free community licenses, [join our Slack channel](http://a8r.io/slack) to talk with other users in the community and get your questions answered.
 
-If you can’t find an answer there, [contact us](/contact-us) to learn more about the support options available with $AESproductName$ Enterprise.
+If you can’t find an answer there, [contact us](/contact-us) to learn more about the support options available with Ambassador Edge Stack Enterprise.
 
-### $AESproductName$ Enterprise
+### Ambassador Edge Stack Enterprise
 
-With $AESproductName$ Enterprise, you have access to deployment and production support. To learn more, [contact sales](/contact-us).
+With Ambassador Edge Stack Enterprise, you have access to deployment and production support. To learn more, [contact sales](/contact-us).
 
-**Deployment and Update Support**: $AESproductName$ can accelerate your migration to Kubernetes, or your upgrade between versions of $AESproductName$. Deployment support helps you with the $AESproductName$ and Kubernetes migration, before you move to production.
+**Deployment and Update Support**: Ambassador Edge Stack can accelerate your migration to Kubernetes, or your upgrade between versions of Ambassador Edge Stack. Deployment support helps you with the Ambassador Edge Stack and Kubernetes migration, before you move to production.
 
-**Production Support**: We offer two types of production support contracts for users deploying the $AESproductName$ in production. We offer both business hour (8am - 5pm EST, M-F) and 24x7 Sev 1 support for the $AESproductName$. 24x7 Sev 1 support includes custom hotfix support for production outages if necessary.
+**Production Support**: We offer two types of production support contracts for users deploying the Ambassador Edge Stack in production. We offer both business hour (8am - 5pm EST, M-F) and 24x7 Sev 1 support for the Ambassador Edge Stack. 24x7 Sev 1 support includes custom hotfix support for production outages if necessary.
 
 ## File a Github Issue
 

content/en/docs/3.8/howtos/_index.md

@@ -21,7 +21,7 @@ These guides are designed to help users quickly accomplish common tasks. The gui
 * Security. Emissary supports a number of strategies for securing Kubernetes services.
   * [Protecting the Diagnostics Interface](protecting-diag-access)
   * [HTTPS and TLS termination](tls-termination)
-  * [Certificate Manager](cert-manager) can be used to automatically obtain and renew TLS certificates; $AESproductName$ natively integrates this functionality.
+  * [Certificate Manager](cert-manager) can be used to automatically obtain and renew TLS certificates; Ambassador Edge Stack natively integrates this functionality.
   * [Client Certificate Validation](client-cert-validation)
   * [Basic Authentication](basic-auth) is a tutorial on how to use the external authentication API to code your own authentication service.
   * [Basic Rate Limiting](rate-limiting-tutorial)

content/en/docs/3.8/howtos/cert-manager.md

@@ -2,18 +2,18 @@
 title: Using cert-manager
 ---
 
-$AESproductName$ has simple and easy built-in support for automatically [using ACME] with the
+Ambassador Edge Stack has simple and easy built-in support for automatically [using ACME] with the
 `http-01` challenge to create and renew TLS certificates. However, this support is not available
-in $OSSproductName$, and it is limited to the ACME `http-01` challenge type. If you're running
-$OSSproductName$, or if you require more flexible certificate management (such as using ACME's
+in Emissary, and it is limited to the ACME `http-01` challenge type. If you're running
+Emissary, or if you require more flexible certificate management (such as using ACME's
 `dns-01` challenge, or using a non-ACME certificate source), external certificate management
 tools are also supported.
 
 [using ACME]: ../../topics/running/host-crd
 
 One such tool is Jetstack's [cert-manager](https://github.com/jetstack/cert-manager), which is a general-purpose tool
 for managing certificates in Kubernetes.  Cert-manager will automatically create and renew TLS certificates and store
-them as Kubernetes secrets for easy use in a cluster.  $productName$ will automatically watch for secret
+them as Kubernetes secrets for easy use in a cluster.  Emissary will automatically watch for secret
 changes and reload certificates upon renewal.
 
 > **Note:** This document assumes cert-manager v0.15 or greater.  This document has been updated to use CRD standards

content/en/docs/3.8/howtos/client-cert-validation.md

@@ -6,16 +6,16 @@ Sometimes, for additional security or authentication purposes, you will want
 the server to validate who the client is before establishing an encrypted
 connection.
 
-To support this, $productName$ can be configured to use a provided CA certificate
+To support this, Emissary can be configured to use a provided CA certificate
 to validate certificates sent from your clients. This allows for client-side
-mTLS where both $productName$ and the client provide and validate each other's
+mTLS where both Emissary and the client provide and validate each other's
 certificates.
 
 ## Prerequisites
 
 - [openssl](https://www.openssl.org/source/) For creating client certificates
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-- [$productName$](../../tutorials/getting-started)
+- [Emissary](../../tutorials/getting-started)
 - [cURL](https://curl.haxx.se/download.html)
 
 
@@ -30,7 +30,7 @@ certificates.
    ```
 
    Enter a passcode for PEM files and fill in the certificate information.
-   Since this certificate will only be shared between a client and $productName$,
+   Since this certificate will only be shared between a client and Emissary,
    the Common Name must be set to something. Everything else can be left blank.
 
    **Note:** If using MacOS,
@@ -55,7 +55,7 @@ certificates.
    kubectl create secret generic client-cacert --from-file=tls.crt=cert.pem
    ```
 
-3. Configure $productName$ to use this certificate for client certificate validation.
+3. Configure Emissary to use this certificate for client certificate validation.
 
    First create a `Host` to manage your domain:
 
@@ -84,14 +84,14 @@ certificates.
       - host.example.com
       secret: host.example.com
       ca_secret: client-cacert
-      cert_required: false      # Optional: Configures $productName$ to reject the request if the client does not provide a certificate. Default: false
+      cert_required: false      # Optional: Configures Emissary to reject the request if the client does not provide a certificate. Default: false
     ```
 
-    **Note**: Client certificate validation requires $productName$ be configured to terminate TLS
+    **Note**: Client certificate validation requires Emissary be configured to terminate TLS
 
-    $productName$ is now be configured to validate certificates that the client provides.
+    Emissary is now be configured to validate certificates that the client provides.
 
-4. Test that $productName$ is validating the client certificates with `curl`
+4. Test that Emissary is validating the client certificates with `curl`
 
    **Linux**:
    ```
@@ -104,7 +104,7 @@ certificates.
    ```
 
    Looking through the verbose output, you can see we are sending a client
-   certificate and $productName$ is validating it.
+   certificate and Emissary is validating it.
 
    If you need further proof, simply create a new set of certificates and
-   try sending the curl with those. You will see $productName$ deny the request.
+   try sending the curl with those. You will see Emissary deny the request.