OSSMDOC-705: Update deprecation statement for Service Mesh Extension API

rh-tokeefe · rh-tokeefe · commit d042efec84cd · 2022-11-14T14:15:14.000-05:00
diff --git a/modules/ossm-control-plane-cli.adoc b/modules/ossm-control-plane-cli.adoc
@@ -83,5 +83,4 @@ istiod-basic-55d78bbbcd-j5556          1/1     Running   0          108s
 jaeger-67c75bd6dc-jv6k6                2/2     Running   0          65m
 kiali-6476c7656c-x5msp                 1/1     Running   0          43m
 prometheus-58954b8d6b-m5std            2/2     Running   0          66m
-wasm-cacher-basic-8c986c75-vj2cd       1/1     Running   0          65m
 ----
diff --git a/modules/ossm-extensions-migrating-to-wasmplugin.adoc b/modules/ossm-extensions-migrating-to-wasmplugin.adoc
@@ -12,11 +12,6 @@ To upgrade your WebAssembly extensions from the `ServiceMeshExtension` API to th
 
 * `ServiceMeshControlPlane` is upgraded to version 2.2 or later.
 
-[CAUTION]
-====
-Because both plug-ins will be called for every request, you might want to remove your existing `ServiceMeshExtension` resource before creating the new `WasmPlugin` resource. You might get undesired results having two plug-ins active at the same time.
-====
-
 .Procedure
 
 . Update your container image. If the plug-in is already in `/plugin.wasm` inside the container, skip to the next step.  If not:
diff --git a/modules/ossm-extensions-migration-overview.adoc b/modules/ossm-extensions-migration-overview.adoc
@@ -6,7 +6,7 @@ This module included in the following assemblies:
 [id="ossm-extensions-migration-overview_{context}"]
 = Migrating from `ServiceMeshExtension` to `WasmPlugin` resources
 
-The `ServiceMeshExtension` API is deprecated as of {SMProductName} version 2.2 and will be removed in a future release. If you are using the `ServiceMeshExtention` API, you must migrate to the `WasmPlugin` API to continue using your WebAssembly extensions.
+The `ServiceMeshExtension` API, which was deprecated in {SMProductName} version 2.2, was removed in {SMProductName} version 2.3. If you are using the `ServiceMeshExtension` API, you must migrate to the `WasmPlugin` API to continue using your WebAssembly extensions.
 
 The APIs are very similar. The migration consists of two steps:
 
diff --git a/modules/ossm-extensions-overview.adoc b/modules/ossm-extensions-overview.adoc
@@ -16,7 +16,7 @@ WebAssembly modules can be run on many platforms, including proxies, and have br
 
 [NOTE]
 ====
-When creating new WebAssembly extensions, use the WasmPlugin API. The ServiceMeshExtension API is deprecated as of {SMProductName} version 2.2 and will be removed in a future release.
+When creating new WebAssembly extensions, use the `WasmPlugin` API. The `ServiceMeshExtension` API was deprecated in {SMProductName} version 2.2 and was removed in {SMProductName} version 2.3.
 ====
 
 There are two parts to writing a {SMProductName} extension:
diff --git a/modules/ossm-extensions-ref-smextension.adoc b/modules/ossm-extensions-ref-smextension.adoc
@@ -13,7 +13,7 @@ The ServiceMeshExtension API provides a mechanism to extend the functionality pr
 
 [NOTE]
 ====
-When creating new WebAssembly extensions, use WasmPlugin. ServiceMeshExtension is deprecated as of {SMProductName} version 2.2 and will be removed in a future release.
+When creating new WebAssembly extensions, use the `WasmPlugin` API. The `ServiceMeshExtension` API, which was deprecated in {SMProductName} version 2.2, was removed in {SMProductName} version 2.3.
 ====
 
 .ServiceMeshExtension Field Reference
diff --git a/modules/ossm-extensions-ref-wasmplugin.adoc b/modules/ossm-extensions-ref-wasmplugin.adoc
@@ -10,7 +10,7 @@ The WasmPlugins API provides a mechanism to extend the functionality provided by
 
 You can deploy multiple WasmPlugins. The `phase` and `priority` settings determine the order of execution (as part of Envoy's filter chain), allowing the configuration of complex interactions between user-supplied WasmPlugins and Istio’s internal filters.
 
-In the following example, an authentication filter implements an OpenID flow and populates the Authorization header with a JSON Web Token (JWT). Istio authentication consumes this token and deployes it to the ingress gateway. The WasmPlugin file lives in the proxy sidecar filesystem. Note the field `url`.
+In the following example, an authentication filter implements an OpenID flow and populates the Authorization header with a JSON Web Token (JWT). Istio authentication consumes this token and deploys it to the ingress gateway. The WasmPlugin file lives in the proxy sidecar filesystem. Note the field `url`.
 
 [source,yaml]
 ----
diff --git a/modules/ossm-extensions-smextension-deploy.adoc b/modules/ossm-extensions-smextension-deploy.adoc
@@ -10,7 +10,7 @@ You can enable {SMProductName} extensions using the `ServiceMeshExtension` resou
 
 [NOTE]
 ====
-When creating new WebAssembly extensions, use WasmPlugin. ServiceMeshExtension is deprecated as of {SMProductName} version 2.2 and will be removed in a future release.
+When creating new WebAssembly extensions, use the `WasmPlugin` API. The `ServiceMeshExtension` API was deprecated in {SMProductName} version 2.2 and removed in {SMProductName} version 2.3.
 ====
 
 For a complete example that was built using the Rust SDK, take a look at the link:https://github.com/maistra/header-append-filter[header-append-filter]. It is a simple filter that appends one or more headers to the HTTP responses, with their names and values taken out from the `config` field of the extension. See a sample configuration in the snippet below.
diff --git a/modules/ossm-extensions-smextension-format.adoc b/modules/ossm-extensions-smextension-format.adoc
@@ -10,7 +10,7 @@ You must have a `.wasm` file containing the bytecode of your WebAssembly module,
 
 [NOTE]
 ====
-When creating new WebAssembly extensions, use WasmPlugin. ServiceMeshExtension is deprecated as of {SMProductName} version 2.2 and will be removed in a future release.
+When creating new WebAssembly extensions, use the `WasmPlugin` API. The `ServiceMeshExtension` API was deprecated in {SMProductName} version 2.2 and was removed in {SMProductName} version 2.3.
 ====
 
 .manifest.yaml
diff --git a/modules/ossm-upgrade-21-22-changes.adoc b/modules/ossm-upgrade-21-22-changes.adoc
@@ -11,4 +11,4 @@ Upgrading the {SMProductShortName} control plane from version 2.1 to 2.2 introdu
 
 * Istio 1.10 updated Envoy to send traffic to the application container using `eth0` rather than `lo` by default.
 
-* This release adds support for the `WasmPlugin` API and deprecates the `ServiceMeshExtention` API.
+* This release adds support for the `WasmPlugin` API and deprecates the `ServiceMeshExtension` API.
diff --git a/modules/ossm-validating-smcp.adoc b/modules/ossm-validating-smcp.adoc
@@ -13,7 +13,6 @@ When you create the {SMProductShortName} control plane, the {SMProductShortName}
 ** `istio-egressgateway`
 ** `grafana`
 ** `prometheus`
-** `wasm-cacher`
 * Calls the Kiali Operator to create Kaili deployment based on configuration in either the SMCP or the Kiali custom resource.
 +
 [NOTE]
@@ -81,7 +80,6 @@ istiod-basic-6c9cc55998-wg4zq          1/1     Running   0          2m14s
 jaeger-6865d5d8bf-zrfss                2/2     Running   0          100s
 kiali-579799fbb7-8mwc8                 1/1     Running   0          46s
 prometheus-5c579dfb-6qhjk              2/2     Running   0          115s
-wasm-cacher-basic-5b99bfcddb-m775l     1/1     Running   0          86s
 ----
 +
 . Check the status of the {SMProductShortName} control plane deployment by using the following command. Replace `istio-system` with the namespace where you deployed the SMCP.

Original file line number	Diff line number	Diff line change
`@@ -11,4 +11,4 @@ Upgrading the {SMProductShortName} control plane from version 2.1 to 2.2 introdu`
`11`	`11`
`12`	`12`	* Istio 1.10 updated Envoy to send traffic to the application container using `eth0` rather than `lo` by default.
`13`	`13`
`14`		-* This release adds support for the `WasmPlugin` API and deprecates the `ServiceMeshExtention` API.
	`14`	+* This release adds support for the `WasmPlugin` API and deprecates the `ServiceMeshExtension` API.