Synchronization getambassador.io ->ambassador-docs -- Nightly job - 2023-10-09

docs/cloud/latest/cloud-features.yml

@@ -1,9 +1,5 @@
 # Cloud features should be represented as objects, path always starting with '/' and ending without '/'.
 
-- {
-    path: /docs/cloud/latest/onboarding-dashboard,
-    feature: Team collaboration,
-  }
 - {
     path: /docs/cloud/latest/service-catalog/concepts/services,
     feature: Team collaboration,
@@ -20,10 +16,6 @@
     path: /docs/cloud/latest/service-catalog/howtos/cells,
     feature: Team collaboration,
   }
-- {
-    path: /docs/cloud/latest/onboarding-dashboard,
-    feature: Team collaboration,
-  }
 
 - {
     path: /docs/cloud/latest/service-catalog/howtos/intercept,

docs/cloud/latest/onboarding-dashboard/index.md

@@ -5,26 +5,24 @@ description: "In this section, you can see the ambassador onboarding procces of
 
 # Onboarding Dashboard
 
-A central location to see the status of your developers, and the services within your organization.
+A central location to check the status of your developers, or the count of telepresence connections to your clusters.
 
 ## Onboarding Overview
 
-All the members of your organization can look at the onboarding dashboard to see which invited developers haven't onboarded and which have. You can also invite new developers here, or see which services are in use across your organization.
+All members of your organization have the ability to access the dashboard, where they can clearly identify invited developers who have not yet joined, as well as those who have. Furthermore, from this dashboard, you can send invitations to new developers (excluding Developer and Lite subscriptions).
+In addition to this, easy access is provided to information about your clusters, as well as the features developed by Ambassador.
 
 <p align="center">
   <img src="../images/onboarding-dashboard.png" width="600" alt="Onboarding dashboard" />
 </p>
 
-<p align="center">
-  <img src="../images/onboarding-active-services.png" width="600" alt="Active services" />
-</p>
 
-<p align="center">
-  <img src="../images/onboarding-latest-intercepts.png" width="600" alt="Latest intercepts" />
-</p>
+- **Connects:** Total telepresence connections made to your clusters.
+- **Clusters:** Your clusters set up through Ambassador Cloud.
+- **Features:**  Additional functionalities that Ambassador provides for you and your organization.
 
+Team members section is  available for all subscriptions except Lite and Developer:
 - **Invite more people:** Invite your colleagues to collaborate, send an email invitation link to start the Ambassador Cloud experience.
 - **Re-Invite people:** Resend the invite to colleagues that didn't accept the first invite.
 - **Developers onboarded:** See the number of people that have created or initialized an intercept.
 - **Need to be onboarded:** List of people who have not created any intercept. You can nudge them to send some useful email with instructions about how to start.
-- **Active services:** Your services that are currently flagged as `active`, how they were activated, and the last seen date.

docs/cloud/latest/releaseNotes.yml

@@ -30,6 +30,12 @@
 
 changelog: ''
 items:
+  - date: '2023-10-02'
+    notes:
+      - title: 'Organization Dashboard redesign'
+        body: The Dashboard was redesigned to better highlight users and organization's usage of Telepresence and Edge Stack.
+        image: './new-organization-dashboard.png'
+        type: feature
   - date: '2023-08-29'
     notes:
       - title: 'New subscription plans'

docs/edge-stack/latest/about/aes-emissary-eol.md

@@ -0,0 +1,56 @@
+# $productName$ End of Life Policy
+
+This document describes the End of Life policy and maintenance windows for Ambassador Edge Stack, and to the open source project Emissary Ingress.
+
+## Supported Versions
+
+Ambassador Edge Stack and 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.
+
+**X-series (Major Versions)**
+
+- **1.y**: 1.0 GA on January 2020
+- **2.y**: 2.0.4 GA on October 2021, and 2.1.0 in December 2021.
+
+**Y-release (Minor versions)**
+
+- For 1.y, that is **1.14.z**
+- For 2.y, that is **2.3.z**
+
+In this document, **Current** refers to the latest X-series release.
+
+Maintenance refers to the previous X-series release, including security and Sev1 defect patches.
+
+## CNCF Ecosystem Considerations
+
+- Envoy releases a major version every 3 months and supports its previous releases for 12 months. Envoy does not support any release longer than 12 months.
+- Kubernetes 1.19 and newer receive 12 months of patch support (The [Kubernetes Yearly Support Period](https://github.com/kubernetes/enhancements/blob/master/keps/sig-release/1498-kubernetes-yearly-support-period/README.md)).
+
+# The Policy
+
+> We will offer a 6 month maintenance window for the latest Y-release of an X-series after a new X-series goes GA and becomes the current release. For example, we will support 2.3 for severity 1 and defect patches for six months after 3.0 is released.
+>
+
+> During the maintenance window, Y-releases will only receive security and Sev1 defect patches. Users desiring new features or bug fixes for lower severity defects will need to upgrade to the current X-series.
+>
+
+> The current X-series will receive as many Y-releases as necessary and as often as we have new features or patches to release.
+>
+
+> Ambassador Labs offers no-downtime migration to current versions from maintenance releases. Migration from releases that are outside of the maintenance window may be subject to downtime.
+>
+
+> Artifacts of releases outside of the maintenance window will be frozen and will remain available publicly for download with the best effort. These artifacts include Docker images, application binaries, Helm charts, etc.
+>
+
+### When we say support with “defect patches”, what do we mean?
+
+- We will fix security issues in our Emissary-ingress and Ambassador Edge Stack code
+- 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
+
+## Extended Maintenance for 1.14
+
+Given this policy, we should have dropped maintenance for 1.14 in March 2022, however we recognize that the introduction of an EOL policy necessitates a longer maintenance window. For this reason, we do offer an "extended maintenance" window for 1.14 until the end of September 2022, 3 months after the latest 2.3 release. Please note that this extended maintenance window will not apply to customers using Kubernetes 1.22 and above, and this extended maintenance will also not provide a no-downtime migration path from 1.14 to 3.0.
+
+After September 2022, the current series will be 3.x, and the maintenance series will be 2.y.

docs/edge-stack/latest/about/changes-2.x.md

@@ -0,0 +1,243 @@
+import Alert from '@material-ui/lab/Alert';
+
+Major Changes in $productName$ 2.X
+==================================
+
+The 2.X family introduces a number of changes to allow $productName$
+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 $productName$ 2 is functionally compatible with $productName$ 1.14, note
+that this is a **major version change** and there are important differences between
+$productName$ 1.X and $productName$ $version$. For details, read on.
+
+## 1. Configuration API Version `getambassador.io/v3alpha1`
+
+$productName$ 2.0 introduced API version `getambassador.io/v3alpha1` to allow
+certain changes in configuration resources that are not backwards compatible with
+$productName$ 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">
+  $productName$ 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>
+
+API version `getambassador.io/v3alpha1` replaces `x.getambassador.io/v3alpha1` from
+the 2.0 developer previews. `getambassador.io/v3alpha1` may still change as we receive
+feedback.
+
+## 2. Kubernetes 1.22 and Structural CRDs
+
+Kubernetes 1.22 requires [<i>structural CRDs</i>](https://kubernetes.io/blog/2019/06/20/crd-structural-schema/).
+This change is primarily meant to support better CRD validation, but it also has the
+effect that union types are no longer allowed in CRDs: for example, an element that can be
+either a string or a list of strings is not allowed. Several such elements appeared in the
+`getambassador.io/v2` CRDs, requiring changes. In `getambassador.io/v3alpha1`:
+
+- `ambassador_id` must always be a list of strings
+- `Host.mappingSelector` supersedes `Host.selector`, and controls association between Hosts and Mappings
+- `Mapping.hostname` supersedes `Mapping.host` and `Mapping.host_regex`
+- `Mapping.tls` can only be a string
+- `Mapping.labels` always requires maps instead of strings
+
+## 2. `Listener`s, `Host`s, and `Mapping`s
+
+$productName$ 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 $productName$ 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 $productName$, and must be defined by the user.** If you do not
+define any `Listener`s, $productName$ 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
+
+- `port`: a port number on which to listen for new requests;
+- `protocol` and `securityModel`: the protocol stack and security model to use (e.g. `HTTPS` using the `X-Forwarded-Proto` header); and
+- `hostBinding`: how to tell if a given `Host` should be associated with this `Listener`:
+   - a `Listener` can choose to consider all `Host`s, or only `Host`s in the same namespace as the `Listener`, or
+   - a `Listener` can choose to consider only `Host`s with a particular Kubernetes `label`.
+
+**Note that the `hostBinding ` is mandatory.** A `Listener` _must_ specify how to identify the `Host`s to associate with the `Listener`', or the `Listener` will be rejected. This is intended to help prevent cases where a `Listener` mistakenly grabs too many `Host`s: if you truly need a `Listener` that associates with all `Host`s, the easiest way is to tell the `Listener` to look for `Host`s in all namespaces, with no further selectors, for example:
+
+```yaml
+apiVersion: getambassador.io/v3alpha1
+kind: listener
+metadata:
+  name: all-hosts-listener
+spec:
+  port: 8080
+  securityModel: XFP
+  protocol: HTTPS
+  hostBinding:
+    namespace:
+      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 $productName$.
+
+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.
+
+<Alert severity="info">
+  <a href="../../topics/running/listener">Learn more about <code>Listener</code></a>.<br/>
+  <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.
+</Alert>
+
+### Wildcard `Host`s No Longer Created
+
+In $productName$ 1.X, $productName$ would make sure that a wildcard `Host`, with a `hostname` of `"*"`, was always present.
+$productName$ 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 $productName$ **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:
+
+- requests to `http://foo.example.com/` will work, but
+- requests to `http://10.11.12.13/` will **not** work.
+
+Adding a `Host` with a `hostname` of `"*"` will allow the second query to work.
+
+<Alert severity="info">
+  <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.
+</Alert>
+
+### `Host` and `Mapping` Association
+
+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 $productName$ 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.
+
+   - Note that a `getambassador.io/v2` `Mapping` has `host` and `host_regex`, rather than `hostname`.
+      - A `getambassador.io/v3alpha1` `Mapping` will honor `host` and `host_regex` as a transition aid, but `host` and `host_regex` are deprecated in favor of `hostname`.
+      - A `Mapping` that specifies `host_regex: true` will be associated with all `Host`s. This is generally far less desirable than using `hostname` with a DNS glob.
+
+- The `Host` specifies a `mappingSelector` that matches the `Mapping`'s Kubernetes `label`s.
+
+   - Note that a `getambassador.io/v2` `Host` has a `selector`, rather than a `mappingSelector`.
+      - A `getambassador.io/v3alpha1` `Host` ignores `selector` and, instead, looks only at `mappingSelector`.
+      - Where a `selector` got a default value if not specified, `mappingSelector` must be explicitly stated.
+
+Without either a `hostname` match or a `label` match, the `Mapping` will not be associated with the `Host` in question. This is intended to help manage memory consumption with large numbers of `Host`s and large numbers of `Mapping`s.
+
+<Alert severity="info">
+  <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.<br/>
+  <a href="../../topics/using/intro-mappings">Learn more about <code>Mapping</code></a>.
+</Alert>
+
+### Independent `Host` Actions
+
+Each `Host` can specify its `requestPolicy.insecure.action` independently of any other `Host`, allowing for HTTP routing as flexible as HTTPS routing.
+
+<Alert severity="info">
+  <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.
+</Alert>
+
+### `Host`, `TLSContext`, and TLS Termination
+
+As of $productName$ 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:
+
+```yaml
+---
+kind: Secret
+type: kubernetes.io/tls
+metadata:
+  name: minimal-secret
+data:
+  tls secret goes here
+---
+apiVersion: getambassador.io/v3alpha1
+kind: Host
+metadata:
+  name: minimal-host
+spec:
+  hostname: minimal.example.com
+  tlsSecret:
+    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 $productName$ Communications](../../howtos/configure-communications).
+
+<Alert severity="info">
+  <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.<br/>
+  <a href="../../topics/running/tls/#tlscontext">Learn more about <code>TLSContext</code></a>.
+</Alert>
+
+### `Mapping`s, `TCPMapping`s, and TLS Origination
+
+A `getambassador.io/v2` `Mapping` or `TCPMapping` could specify `tls: true` to indicate TLS origination without supplying a certificate. This is not supported in `getambassador.io/v3alpha1`: instead, use an `https://` prefix on the `service`. In the [Mapping](../../topics/using/mappings/#using-tls), this is straightforward, but [there are more details for the `TCPMapping` when using TLS](../../topics/using/tcpmappings/#tcpmapping-and-tls).
+
+<Alert severity="info">
+  <a href="../../topics/using/intro-mappings">Learn more about <code>Mapping</code></a>.
+</Alert>
+
+### `Mapping`s and `labels`
+
+The `Mapping` CRD includes a `labels` field, used with rate limiting. The
+[syntax of the `labels`](../../topics/using/rate-limits#attaching-labels-to-requests) has changed
+for compatibility with Kubernetes 1.22.
+
+<Alert severity="info">
+  <a href="../../topics/using/intro-mappings">Learn more about <code>Mapping</code></a>.
+</Alert>
+
+### `Host`s and ACME
+
+In $productName$ 2.0, ACME will be disabled if a `Host` does not set `acmeProvider` at all (prior to $productName$ 2.0, not mentioning `acmeProvider` would result in the ACME client attempting, and failing, to start). If `acmeProvider` is set, but `acmeProvider.authority` is not set, the ACME client will continue to default to Let's Encrypt, in order to preserve compatibility with $productName$ prior to $productName$ 2.0. For further examples, see [Configuring $productName$ to Communicate](../../howtos/configure-communications).
+
+<Alert severity="info">
+  <a href="../../topics/running/host-crd">Learn more about <code>Host</code></a>.
+</Alert>
+
+## 3. Other Changes
+
+### Envoy V3 API by Default
+
+By default, $productName$ 2.X will configure Envoy using the
+[V3 Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api-v3/api).
+
+### More Performant Reconfiguration by Default
+
+In $productName$ 1.X, the environment variable `AMBASSADOR_FAST_RECONFIGURE` could be used to enable a higher performance implementation of the code $productName$ 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 $productName$ 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.
+
+<Alert severity="info">
+  <a href="../../topics/running/listener">Learn more about <code>Listener</code></a>.
+</Alert>
+
+### `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 $productName$ Communications](../../howtos/configure-communications).
+
+### Service Preview No Longer Supported
+
+Service Preview is no longer supported as of $productName$ 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 $productName$ 2.X, in favor of Ambassador Cloud.
+
+### `Project` CRD No Longer Supported
+
+The `Project` CRD has been removed as of $productName$ 2.X, in favor of Argo.