fix(templating): fix mesh product name templating (#1380)

Signed-off-by: slonka <[email protected]>

app/_src/documentation/configuration.md

@@ -52,7 +52,7 @@ helm install -f values.yaml {{ site.kuma_install_name }} {{ site.mesh_helm_repo
 If you have a lot of configuration you can just write them all in a YAML file and use:
 
 ```shell
-helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file controlPlace.config=cp-conf.yaml
+helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file {{set_flag_values_prefix}}controlPlane.config=cp-conf.yaml
 ```
 The value of the configmap `{{site.mesh_cp_name}}-config` is now the content of `cp-conf.yaml`.
 

app/_src/explore/gateway-api.md

@@ -43,7 +43,7 @@ Gateway API [`Gateways`](https://gateway-api.sigs.k8s.io/api-types/gateway/) are
    The `Gateway` resource represents the proxy instance that handles traffic for a set of Gateway API routes.
 
    Every `Gateway` refers to a [`GatewayClass`](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/).
-   The `GatewayClass` represents the class of `Gateway`, in this case Kuma's builtin edge
+   The `GatewayClass` represents the class of `Gateway`, in this case {{site.mesh_product_name}}'s builtin edge
    gateway, and points to a controller that should manage these `Gateways`. It can also hold
    [additional configuration](#customization).
 

app/_src/policies/how-kuma-chooses-the-right-policy-to-apply.md

@@ -43,7 +43,7 @@ conf:
   backend: splunk
 ```
 
-What does `Kuma` do when it encounters multiple matching policies?
+What does {{site.mesh_product_name}} do when it encounters multiple matching policies?
 
 ## General rules
 

app/_src/policies/meshloadbalancingstrategy.md

@@ -131,7 +131,7 @@ kind: MeshLoadBalancingStrategy
 apiVersion: kuma.io/v1alpha1
 metadata:
   name: ring-hash
-  namespace: kuma-system
+  namespace: {{site.mesh_namespace}}
   labels:
     kuma.io/mesh: mesh-1
 spec:
@@ -196,7 +196,7 @@ kind: MeshLoadBalancingStrategy
 apiVersion: kuma.io/v1alpha1
 metadata:
   name: disable-la-to-backend
-  namespace: kuma-system
+  namespace: {{site.mesh_namespace}}
   labels:
     kuma.io/mesh: mesh-1
 spec:

app/_src/policies/protocol-support-in-kuma.md

@@ -2,7 +2,7 @@
 title: Protocol support in Kuma
 ---
 
-At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic.
+At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic.
 
 For `http`, `grpc` and `kafka` traffic {{site.mesh_product_name}} provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics.
 
@@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa
 
 {{site.mesh_product_name}} out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`.
 
-As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for {{site.mesh_product_name}} to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.:
+As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for {{site.mesh_product_name}} to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.:
 
 {% tabs websocket-support useUrlFragment=false %}
 {% tab websocket-support Kubernetes %}

app/_src/policies/traffic-metrics.md

@@ -9,7 +9,7 @@ You can add metrics to a mesh configuration, or to an individual data plane prox
 {{site.mesh_product_name}} provides full integration with Prometheus:
 
 * Each proxy can expose its metrics in [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format).
-* Because metrics are part of the mesh configuration, Kuma exposes an API called the monitoring assignment service (MADS) which exposes every proxy in the mesh.
+* Because metrics are part of the mesh configuration, {{site.mesh_product_name}} exposes an API called the monitoring assignment service (MADS) which exposes every proxy in the mesh.
 
 To collect metrics from {{site.mesh_product_name}}, you need to expose metrics from proxies and applications. 
 

app/_src/production/dp-config/cni.md

@@ -220,7 +220,7 @@ helm install --create-namespace --namespace {{site.mesh_namespace}} \
 {% tab insallation OpenShift 3.11 %}
 
 1. Follow the instructions in [OpenShift 3.11 installation](/docs/{{ page.version }}/installation/openshift/#2-run-kuma)
-   to get the `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` enabled (this is required for regular kuma installation).
+   to get the `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` enabled (this is required for regular {{site.mesh_product_name}} installation).
 
 2. You need to grant privileged permission to kuma-cni service account:
 

app/_src/production/upgrades-tuning/fine-tuning.md

@@ -18,7 +18,7 @@ Follow the {% if_version lte:2.1.x %}[transparent proxying](/docs/{{ page.versio
 
 ## Postgres
 
-If you choose `Postgres` as a configuration store for `Kuma` on Universal,
+If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal,
 please be aware of the following key settings that affect performance of {{site.mesh_product_name}} Control Plane.
 
 * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s)

app/docs/1.2.x/documentation/cli.md

@@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables:
 * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`.
 * `envoy`: this is the Envoy executable that we bundle for convenience into the archive.
 * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data.
-* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them.
+* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them.
 * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes.
 
 According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly.
@@ -52,4 +52,4 @@ Available commands on `kumactl` are:
 * `kumactl generate tls-certificate`: used to generate a TLS certificate for client or server.
 * `kumactl manage ca [..]`: used to manage certificate authorities.
 * `kumactl help [..]`: help dialog that explains the commands available.
-* `kumactl version [--detailed]`: shows the version of the program.
+* `kumactl version [--detailed]`: shows the version of the program.

app/docs/1.2.x/documentation/dps-and-data-model.md

@@ -117,7 +117,7 @@ E.g.,
 * you can turn `Envoy Admin API` off by using `--admin-port=`
 
 {% warning %}
-If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of `Kuma` features, such as enabling `Prometheus` metrics on that dataplane.
+If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of {{site.mesh_product_name}} features, such as enabling `Prometheus` metrics on that dataplane.
 {% endwarning %}
 
 ## Tags

app/docs/1.2.x/documentation/fine-tuning.md

@@ -4,7 +4,7 @@ title: Fine-tuning
 
 ## Postgres
 
-If you choose `Postgres` as a configuration store for `Kuma` on Universal,
+If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal,
 please be aware of the following key settings that affect performance of Kuma Control Plane.
 
 * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s)
@@ -78,4 +78,4 @@ Then, you can analyze the retrieved profiling data using an application like [Sp
 
 {% warning %}
 After a successful debugging session, please remember to turn off the debugging endpoints since anybody could execute heap dumps on them potentially exposing sensitive data.
-{% endwarning %}
+{% endwarning %}

app/docs/1.2.x/documentation/overview.md

@@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to
 * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`.
 * `envoy`: this is the Envoy executable that we bundle for convenience into the archive.
 * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data.
-* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them.
+* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them.
 * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes.
 
 A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes:

app/docs/1.2.x/policies/general-notes-about-kuma-policies.md

@@ -2,7 +2,7 @@
 title: General notes about Kuma policies
 ---
 
-You may have already noticed that most `Kuma` policies have very similar structure, namely
+You may have already noticed that most {{site.mesh_product_name}} policies have very similar structure, namely
 
 ```yaml
 sources:
@@ -25,7 +25,7 @@ where
 * `destinations` - a list of selectors to match those `Dataplanes` where network traffic destined at
 * `conf` - configuration to apply to network traffic between `sources` and `destinations`
 
-To keep configuration model simple and consistent, `Kuma` assumes that every `Dataplane` represents a `service`, even if it's a cron job that doesn't normally handle incoming traffic.
+To keep configuration model simple and consistent, {{site.mesh_product_name}} assumes that every `Dataplane` represents a `service`, even if it's a cron job that doesn't normally handle incoming traffic.
 
 Consequently, `service` tag is mandatory for `sources` and `destinations` selectors.
 
@@ -87,4 +87,4 @@ For example, policies that get applied on the client side of a connection betwee
 In some cases there is a fundamental technical cause for that (e.g., `TrafficRoute`), in other cases it's a simplification of the initial implementation (e.g., `TrafficLog` and `HealthCheck`).
 
 Please let us know if such constraints become critical to your use case.
-{% endwarning %}
+{% endwarning %}

app/docs/1.2.x/policies/how-kuma-chooses-the-right-policy-to-apply.md

@@ -38,7 +38,7 @@ conf:
   backend: splunk
 ```
 
-What does `Kuma` do when it encounters multiple matching policies?
+What does {{site.mesh_product_name}} do when it encounters multiple matching policies?
 
 ## General rules
 

app/docs/1.2.x/policies/protocol-support-in-kuma.md

@@ -2,7 +2,7 @@
 title: Protocol support in Kuma
 ---
 
-At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic.
+At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic.
 
 For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics.
 
@@ -76,7 +76,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa
 
 Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be annotated with `kuma.io/protocol: tcp` annotation
 
-As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.:
+As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.:
 
 {% tabs websocket-support useUrlFragment=false %}
 {% tab websocket-support Kubernetes %}
@@ -111,4 +111,4 @@ networking:
       kuma.io/protocol: tcp
 ```
 {% endtab %}
-{% endtabs %}
+{% endtabs %}

app/docs/1.2.x/policies/traffic-log.md

@@ -6,7 +6,7 @@ With `TrafficLog` policy you can easily set up access logs on every data-plane i
 
 [//]: # (The logs can be then forwarded to a collector that can further transmit them into systems like Splunk, ELK and Datadog.)
 
-Configuring access logs in `Kuma` is a 3-step process:
+Configuring access logs in {{site.mesh_product_name}} is a 3-step process:
 
 * [1. Add a logging backend](#add-a-logging-backend)
 * [2. Add a TrafficLog resource](#add-a-trafficlog-resource)
@@ -16,7 +16,7 @@ Configuring access logs in `Kuma` is a 3-step process:
 
 A _logging backend_ is essentially a sink for access logs.
 
-In the current release of `Kuma`, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash.
+In the current release of {{site.mesh_product_name}}, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash.
 
 {% tabs logging-backend useUrlFragment=false %}
 {% tab logging-backend Kubernetes %}
@@ -158,7 +158,7 @@ When `backend ` field of a `TrafficLog` policy is omitted, the logs will be forw
 
 ## Log aggregation and visualisation
 
-`Kuma` is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**.
+{{site.mesh_product_name}} is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**.
 
 {% tabs log-aggregation useUrlFragment=false %}
 {% tab log-aggregation Kubernetes %}
@@ -250,7 +250,7 @@ You can also forward the access logs to a collector (such as logstash) that can
 
 ### Access Log Format
 
-`Kuma` gives you full control over the format of access logs.
+{{site.mesh_product_name}} gives you full control over the format of access logs.
 
 The shape of a single log record is defined by a template string that uses [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) to extract and format data about a `TCP` connection or an `HTTP` request.
 
@@ -265,7 +265,7 @@ where `%START_TIME%` and `%KUMA_SOURCE_SERVICE%` are examples of available _comm
 A complete set of supported _command operators_ consists of:
 
 1. All _command operators_ [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators)
-2. _Command operators_ unique to `Kuma`
+2. _Command operators_ unique to {{site.mesh_product_name}}
 
 The latter include:
 
@@ -283,7 +283,7 @@ All access log _command operators_ are valid to use with both `TCP` and `HTTP` t
 
 If a _command operator_ is specific to `HTTP` traffic, such as `%REQ(X?Y):Z%` or `%RESP(X?Y):Z%`, it will be replaced by a symbol "`-`" in case of `TCP` traffic.
 
-Internally, `Kuma` [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`.
+Internally, {{site.mesh_product_name}} [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`.
 
 The default format string for `TCP` traffic is:
 

app/docs/1.2.x/policies/traffic-metrics.md

@@ -95,7 +95,7 @@ By default all available metrics are returned.
 
 {% tabs override useUrlFragment=false %}
 {% tab override Kubernetes %}
-To override `Mesh`-wide defaults for a particular `Pod`, use `Kuma`-specific annotations:
+To override `Mesh`-wide defaults for a particular `Pod`, use {{site.mesh_product_name}}-specific annotations:
 * `prometheus.metrics.kuma.io/port` - to override `Mesh`-wide default port
 * `prometheus.metrics.kuma.io/path` - to override `Mesh`-wide default path
 

app/docs/1.3.x/documentation/cli.md

@@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables:
 * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`.
 * `envoy`: this is the Envoy executable that we bundle for convenience into the archive.
 * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data.
-* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them.
+* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them.
 * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes.
 
 According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly.
@@ -52,4 +52,4 @@ Available commands on `kumactl` are:
 * `kumactl generate tls-certificate`: used to generate a TLS certificate for client or server.
 * `kumactl manage ca [..]`: used to manage certificate authorities.
 * `kumactl help [..]`: help dialog that explains the commands available.
-* `kumactl version [--detailed]`: shows the version of the program.
+* `kumactl version [--detailed]`: shows the version of the program.

app/docs/1.3.x/documentation/dps-and-data-model.md

@@ -117,7 +117,7 @@ E.g.,
 * you can turn `Envoy Admin API` off by using `--admin-port=`
 
 {% warning %}
-If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of `Kuma` features, such as enabling `Prometheus` metrics on that dataplane.
+If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of {{site.mesh_product_name}} features, such as enabling `Prometheus` metrics on that dataplane.
 {% endwarning %}
 
 ## Tags

app/docs/1.3.x/documentation/fine-tuning.md

@@ -4,7 +4,7 @@ title: Fine-tuning
 
 ## Postgres
 
-If you choose `Postgres` as a configuration store for `Kuma` on Universal,
+If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal,
 please be aware of the following key settings that affect performance of Kuma Control Plane.
 
 * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s)
@@ -78,4 +78,4 @@ Then, you can analyze the retrieved profiling data using an application like [Sp
 
 {% warning %}
 After a successful debugging session, please remember to turn off the debugging endpoints since anybody could execute heap dumps on them potentially exposing sensitive data.
-{% endwarning %}
+{% endwarning %}