Merge pull request #4 from ppeble/emissary-ingress-38

Update 3.8 docs to use only Emissary instead of Emissary-ingress

Author: kflynn

content/en/docs/3.8/_index.md

@@ -10,4 +10,4 @@ simple_list: true
 weight: -380 # Weight for doc version vX.Y should be -XY0
 ---
 
-These docs cover everything from setting up and running Emissary-ingress to its operation and usage.
+These docs cover everything from setting up and running Emissary to its operation and usage.

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

@@ -2,7 +2,7 @@
 title: "Alternatives"
 ---
 
-Alternatives to Emissary-ingress fall into three basic categories:
+Alternatives to Emissary fall into three basic categories:
 
 * Hosted API gateways, such as the [Amazon API gateway](https://aws.amazon.com/api-gateway/).
 * Traditional API gateways, such as [Kong](https://konghq.org/).
@@ -14,8 +14,8 @@ Both hosted API gateways and traditional API gateways are:
 * Not Kubernetes-native. They're typically configured using REST APIs, making it challenging to adopt cloud-native patterns such as GitOps and declarative configuration.
 * [Designed for API management, rather than designed for microservices](../../topics/concepts/microservices-api-gateways).
 
-A Layer 7 proxy can be used as an API gateway, but typically requires additional bespoke development to support microservices use cases. In fact, many API gateways package the additional features needed for an API gateway on top of an L7 proxy. Emissary-ingress uses Envoy, while Kong uses NGINX. If you're interested in deploying Envoy directly, we've written an [introductory tutorial](https://www.datawire.io/guide/traffic/getting-started-lyft-envoy-microservices-resilience/).
+A Layer 7 proxy can be used as an API gateway, but typically requires additional bespoke development to support microservices use cases. In fact, many API gateways package the additional features needed for an API gateway on top of an L7 proxy. Emissary uses Envoy, while Kong uses NGINX. If you're interested in deploying Envoy directly, we've written an [introductory tutorial](https://www.datawire.io/guide/traffic/getting-started-lyft-envoy-microservices-resilience/).
 
 ## Istio
 
-[Istio](https://istio.io) is an open-source service mesh, built on Envoy. A service mesh is designed to manage East/West traffic (traffic between servers and your data center), while an API gateway manages North/South traffic (in and out of your data center). Documentation on how to deploy Emissary-ingress with Istio is [here](../../howtos/istio). In general, we've found that North/South traffic is quite different from East/West traffic (i.e., you don't control the client in the North/South use case).
+[Istio](https://istio.io) is an open-source service mesh, built on Envoy. A service mesh is designed to manage East/West traffic (traffic between servers and your data center), while an API gateway manages North/South traffic (in and out of your data center). Documentation on how to deploy Emissary with Istio is [here](../../howtos/istio). In general, we've found that North/South traffic is quite different from East/West traffic (i.e., you don't control the client in the North/South use case).

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

@@ -1,27 +1,27 @@
 ---
-title: Major Changes in Emissary-ingress 2.X
+title: Major Changes in Emissary 2.X
 ---
 
-The 2.X family introduces a number of changes to allow Emissary-ingress
+The 2.X family introduces a number of changes to allow Emissary
 to more gracefully handle larger installations, reduce global configuration to
 better handle multitenant or multiorganizational installations, reduce memory
 footprint, and improve performance. We welcome feedback!! Join us on
 [Slack](http://a8r.io/slack) and let us know what you think.
 
-While Emissary-ingress 2 is functionally compatible with Emissary-ingress 1.14, note
+While Emissary 2 is functionally compatible with Emissary 1.14, note
 that this is a **major version change** and there are important differences between
-Emissary-ingress 1.X and Emissary-ingress $version$. For details, read on.
+Emissary 1.X and Emissary $version$. For details, read on.
 
 ## 1. Configuration API Version `getambassador.io/v3alpha1`
 
-Emissary-ingress 2.0 introduced API version `getambassador.io/v3alpha1` to allow
+Emissary 2.0 introduced API version `getambassador.io/v3alpha1` to allow
 certain changes in configuration resources that are not backwards compatible with
-Emissary-ingress 1.X. The most notable example of change is the addition of the
+Emissary 1.X. The most notable example of change is the addition of the
 **mandatory** `Listener` resource; however, there are important changes
 in `Host` and `Mapping` as well.
 
 <Alert severity="info">
-  Emissary-ingress 2.X supports only API versions <code>getambassador.io/v2</code>
+  Emissary 2.X supports only API versions <code>getambassador.io/v2</code>
   and <code>getambassador.io/v3alpha1</code>. If you are using any resources with
   older API versions, you will need to upgrade them.
 </Alert>
@@ -46,15 +46,15 @@ either a string or a list of strings is not allowed. Several such elements appea
 
 ## 2. `Listener`s, `Host`s, and `Mapping`s
 
-Emissary-ingress 2.0 introduced the new **mandatory** `Listener` CRD, and made some changes
+Emissary 2.0 introduced the new **mandatory** `Listener` CRD, and made some changes
 to the `Host` and `Mapping` resources.
 
 ### The `Listener` CRD
 
-The new [`Listener` CRD](../../topics/running/listener) defines where and how Emissary-ingress should listen for requests from the network, and which `Host` definitions should be used to process those requests.
+The new [`Listener` CRD](../../topics/running/listener) defines where and how Emissary should listen for requests from the network, and which `Host` definitions should be used to process those requests.
 
-**Note that `Listener`s are never created by Emissary-ingress, and must be defined by the user.** If you do not
-define any `Listener`s, Emissary-ingress will not listen anywhere for connections, and therefore won't do
+**Note that `Listener`s are never created by Emissary, and must be defined by the user.** If you do not
+define any `Listener`s, Emissary will not listen anywhere for connections, and therefore won't do
 anything useful. It will log a `WARNING` to this effect.
 
 A `Listener` specifically defines
@@ -81,7 +81,7 @@ spec:
       from: ALL
 ```
 
-A `Listener` that has no associated `Host`s will be logged as a `WARNING`, and will not be included in the Envoy configuration generated by Emissary-ingress.
+A `Listener` that has no associated `Host`s will be logged as a `WARNING`, and will not be included in the Envoy configuration generated by Emissary.
 
 Note also that there is no limit on how many `Listener`s may be created, and as such no limit on the number of ports to which a `Host` may be associated.
 
@@ -92,11 +92,11 @@ Note also that there is no limit on how many `Listener`s may be created, and as
 
 ### Wildcard `Host`s No Longer Created
 
-In Emissary-ingress 1.X, Emissary-ingress would make sure that a wildcard `Host`, with a `hostname` of `"*"`, was always present.
-Emissary-ingress 2.X does **not** force a wildcard `Host`: if you need the wildcard behavior, you will need to create
+In Emissary 1.X, Emissary would make sure that a wildcard `Host`, with a `hostname` of `"*"`, was always present.
+Emissary 2.X does **not** force a wildcard `Host`: if you need the wildcard behavior, you will need to create
 a `Host` with a hostname of `"*"`.
 
-Of particular note is that Emissary-ingress **will not** respond to queries to an IP address unless a wildcard
+Of particular note is that Emissary **will not** respond to queries to an IP address unless a wildcard
 `Host` is present. If `foo.example.com` resolves to `10.11.12.13`, and the only `Host` has a
 `hostname` of `foo.example.com`, then:
 
@@ -113,7 +113,7 @@ Adding a `Host` with a `hostname` of `"*"` will allow the second query to work.
 
 The [`Host` CRD](../../topics/running/host-crd) continues to define information about hostnames, TLS certificates, and how to handle requests that are "secure" (using HTTPS) or "insecure" (using HTTP). The [`Mapping` CRD](../../topics/using/intro-mappings) continues to define how to map the URL space to upstream services.
 
-However, as of Emissary-ingress 2.0, a `Mapping` will not be associated with a `Host` unless at least one of the following is true:
+However, as of Emissary 2.0, a `Mapping` will not be associated with a `Host` unless at least one of the following is true:
 
 - The `Mapping` specifies a `hostname` attribute that matches the `Host` in question.
 
@@ -144,7 +144,7 @@ Each `Host` can specify its `requestPolicy.insecure.action` independently of any
 
 ### `Host`, `TLSContext`, and TLS Termination
 
-As of Emissary-ingress 2.0, **`Host`s are required for TLS termination**. It is no longer sufficient to create a [`TLSContext`](../../topics/running/tls/#tlscontext) by itself; the [`Host`](../../topics/running/host-crd) is required.
+As of Emissary 2.0, **`Host`s are required for TLS termination**. It is no longer sufficient to create a [`TLSContext`](../../topics/running/tls/#tlscontext) by itself; the [`Host`](../../topics/running/host-crd) is required.
 
 The minimal setup for TLS termination is therefore a Kubernetes `Secret` of type `kubernetes.io/tls`, and a `Host` that uses it:
 
@@ -167,7 +167,7 @@ spec:
     name: minimal-secret
 ```
 
-It is **not** necessary to explicitly state a `TLSContext` in the `Host`: setting `tlsSecret` is enough. Of course, `TLSContext` is still the ideal way to share TLS configuration between more than one `Host`. For further examples, see [Configuring Emissary-ingress Communications](../../howtos/configure-communications).
+It is **not** necessary to explicitly state a `TLSContext` in the `Host`: setting `tlsSecret` is enough. Of course, `TLSContext` is still the ideal way to share TLS configuration between more than one `Host`. For further examples, see [Configuring Emissary Communications](../../howtos/configure-communications).
 
 <Alert severity="info">
   <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.<br/>
@@ -196,23 +196,23 @@ for compatibility with Kubernetes 1.22.
 
 ### Envoy V3 API by Default
 
-By default, Emissary-ingress 2.X will configure Envoy using the
-[V3 Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api-v3/api). In Emissary-ingress
+By default, Emissary 2.X will configure Envoy using the
+[V3 Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api-v3/api). In Emissary
 $version$, you may switch back to Envoy V2 by setting the `AMBASSADOR_ENVOY_API_VERSION`
-environment variable to "V2"; in Emissary-ingress 2.2.0, support for the Envoy V2 API (and
+environment variable to "V2"; in Emissary 2.2.0, support for the Envoy V2 API (and
 the `AMBASSADOR_ENVOY_API_VERSION` environment variable) will be removed.
 
 ### More Performant Reconfiguration by Default
 
-In Emissary-ingress 1.X, the environment variable `AMBASSADOR_FAST_RECONFIGURE` could be used to enable a higher performance implementation of the code Emissary-ingress 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 $productName$ 2.X, this higher-performance mode is always enabled.
 
 ### Changes to the `ambassador` `Module`, and the `tls` `Module`
 
 It is no longer possible to configure TLS using the `tls` element of the `ambassador` `Module` or using the `tls` `Module`. Both of these cases are correctly covered by the `TLSContext` resource.
 
 With the introduction of the `Listener` resource, a few settings have moved from the `Module` to the `Listener`.
 
-Configuration for the `PROXY` protocol is part of the `Listener` resource in Emissary-ingress 2.X, so the `use_proxy_protocol` element of the `ambassador` `Module` is no longer supported. Note that the `Listener` resource can configure `PROXY` resource per-`Listener`, rather than having a single global setting. For further information, see the [`Listener` documentation](../../topics/running/listener).
+Configuration for the `PROXY` protocol is part of the `Listener` resource in Emissary 2.X, so the `use_proxy_protocol` element of the `ambassador` `Module` is no longer supported. Note that the `Listener` resource can configure `PROXY` resource per-`Listener`, rather than having a single global setting. For further information, see the [`Listener` documentation](../../topics/running/listener).
 
 `xff_num_trusted_hops` has been removed from the `Module`, and its functionality has been moved to the `l7Depth` setting in the `Listener` resource.
 
@@ -222,16 +222,16 @@ Configuration for the `PROXY` protocol is part of the `Listener` resource in Emi
 
 ### `TLSContext` `redirect_cleartext_from` and `Host` `insecure.additionalPort`
 
-`redirect_cleartext_from` has been removed from the `TLSContext` resource; `insecure.additionalPort` has been removed from the `Host` CRD. Both of these cases are covered by adding additional `Listener`s. For further examples, see [Configuring Emissary-ingress Communications](../../howtos/configure-communications).
+`redirect_cleartext_from` has been removed from the `TLSContext` resource; `insecure.additionalPort` has been removed from the `Host` CRD. Both of these cases are covered by adding additional `Listener`s. For further examples, see [Configuring Emissary Communications](../../howtos/configure-communications).
 
 ### Service Preview No Longer Supported
 
-Service Preview is no longer supported as of Emissary-ingress 2.X, as its use cases are supported by Telepresence.
+Service Preview is no longer supported as of Emissary 2.X, as its use cases are supported by Telepresence.
 
 ### Edge Policy Console No Longer Supported
 
-The Edge Policy Console has been removed as of Emissary-ingress 2.X, in favor of Ambassador Cloud.
+The Edge Policy Console has been removed as of Emissary 2.X, in favor of Ambassador Cloud.
 
 ### `Project` CRD No Longer Supported
 
-The `Project` CRD has been removed as of Emissary-ingress 2.X, in favor of Argo.
+The `Project` CRD has been removed as of Emissary 2.X, in favor of Argo.

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

@@ -1,5 +1,5 @@
 ---
-title: Major Changes in Emissary-ingress 3.X
+title: Major Changes in Emissary 3.X
 ---
 
 The 3.X family introduces a number of changes to ensure $productName$

content/en/docs/3.8/about/emissary-eol.md

@@ -1,12 +1,12 @@
 ---
-title: Emissary-ingress End of Life Policy
+title: Emissary End of Life Policy
 ---
 
-This document describes the End of Life policy and maintenance windows for the open source project Emissary-ingress.
+This document describes the End of Life policy and maintenance windows for the open source project Emissary.
 
 ## Supported Versions
 
-Emissary-ingress versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
+Emissary versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
 
 **X-series (Major Versions)**
 
@@ -45,7 +45,7 @@ Maintenance refers to the previous X-series release, including security and Sev1
 
 ### When we say support with “defect patches”, what do we mean?
 
-- We will fix security issues in our Emissary-ingress
+- We will fix security issues in our Emissary
 - We will pick up security fixes from dependencies as they are made available
 - We will not maintain forks of our major dependencies
 - We will not attempt our own back ports of critical fixes to dependencies which are out of support from their own communities