Replace product shorthand with correct entity

adoc/admin-security-certificates.adoc

@@ -521,7 +521,7 @@ kubectl rollout restart deployment/oidc-gangway -n kube-system
 
 ** Replace the OIDC CA for `kube-apiserver`:
 
-. Copy custom OIDC CA which was used for `oidc-dex` and `oidc-gangway` to [path]`/etc/kubernetes/pki/oidc-ca.crt` on all CaaSP master nodes
+. Copy custom OIDC CA which was used for `oidc-dex` and `oidc-gangway` to [path]`/etc/kubernetes/pki/oidc-ca.crt` on all {productname} master nodes
 +
 [source,bash]
 ----
@@ -538,7 +538,7 @@ sed -i "s|oidc-ca-file: .*|oidc-ca-file: /etc/kubernetes/pki/oidc-ca.crt|" kubea
 kubectl apply -f kubeadm-config.yaml
 ----
 
-. Update `oidc-ca-file` in static pod manifest for kube-apiserver in [path]`/etc/kubernetes/manifests/kube-apiserver.yaml` on all CaaSP master nodes
+. Update `oidc-ca-file` in static pod manifest for kube-apiserver in [path]`/etc/kubernetes/manifests/kube-apiserver.yaml` on all {productname} master nodes
 +
 [source,bash]
 ----

adoc/admin-software-installation.adoc

@@ -222,15 +222,15 @@ The process for migrating an installation from Helm 2 to Helm 3 has been documen
 
 ==== Preconditions
 
-* A healthy CaaSP 4.5 installation with applications deployed using Helm 2 and Tiller.
+* A healthy {productname} 4.5 installation with applications deployed using Helm 2 and Tiller.
 * A system, which `skuba` and `helm` version 2 have run on previously.
 ** The procedure below requires an available internet connection to install the `2to3` plugin.  If the installation is in an air gapped environment, the system may need to be moved back out of the air gapped environment.
 * These instructions are written for a single cluster managed from a single Helm 2 installation. If more than one cluster is being managed by this installation of Helm 2, please reference https://github.com/helm/helm-2to3 for further details and do not do the clean-up step until all clusters are migrated.
 
 
 ==== Migration Procedure
 
-This is a procedure for migrating a CaaSP 4.5 deployment that has used Helm 2 to deploy applications.
+This is a procedure for migrating a {productname} 4.5 deployment that has used Helm 2 to deploy applications.
 
 . Install `helm3` package in the same location you normally run `skuba` commands (alongside the helm2 package):
 +

adoc/admin-troubleshooting-etcd.adoc

@@ -67,7 +67,7 @@ crictl logs -f $etcdcontainer
 
 == etcdctl
 
-`etcdctl` is a command line client for `etcd`. The new version of CaaSP is using the `v3` API. For that, you need to make sure to set environment variable `ETCDCTL_API=3` before using it. Apart from that, you need to provide the required keys and certificates for authentication and authorization, via `ETCDCTL_CACERT`, `ETCDCTL_CERT` and `ETCDCTL_KEY` environment variables. Last but not least, you need to also specify the endpoint via `ETCDCTL_ENDPOINTS` environment variable.
+`etcdctl` is a command line client for `etcd`. The new version of {productname} is using the `v3` API. For that, you need to make sure to set environment variable `ETCDCTL_API=3` before using it. Apart from that, you need to provide the required keys and certificates for authentication and authorization, via `ETCDCTL_CACERT`, `ETCDCTL_CERT` and `ETCDCTL_KEY` environment variables. Last but not least, you need to also specify the endpoint via `ETCDCTL_ENDPOINTS` environment variable.
 
 
 * **Example**

adoc/architecture-description.adoc

@@ -114,7 +114,7 @@ procedures.
 
 ==== Software Management
 
-CaaSP is distributed as a dedicated repository. All required packages
+{productname} is distributed as a dedicated repository. All required packages
 to deploy a node to the cluster are installable via a pattern. This pattern
 will automatically be installed by `skuba` when bootstrapping or
 joining a node.
@@ -377,7 +377,7 @@ plus, the number of workers necessary to host your workloads.
 === Air Gapped Deployment
 
 In air gapped environments, the "Infrastructure node" is mandatory, as
-it's needed to have a local RMT server mirroring the CaaSP
+it's needed to have a local RMT server mirroring the {productname}
 repositories, a mirror of the SUSE container registry and a mirror of
 the SUSE helm chart repository.
 
@@ -579,7 +579,7 @@ first master machine:
 
 This operation will read the `kubeadm-init.conf` file inside your
 cluster definition, will forcefully set certain settings to the ones
-required by CaaSP and will bootstrap the node remotely.
+required by {productname} and will bootstrap the node remotely.
 
 Prior to bootstrap it's possible for you to tweak the configuration
 that will be used to create the cluster. You can:

adoc/deployment-openstack.adoc

@@ -64,7 +64,7 @@ You can set the timezone before deploying the nodes by modifying the following f
 # - systemctl restart sshd
 ----
 +
-. Register your nodes by using the SUSE CaaSP Product Key or by registering nodes against local SUSE Repository Mirroring Server in `~/caasp/deployment/openstack/registration.auto.tfvars`:
+. Register your nodes by using the {productname} Product Key or by registering nodes against local SUSE Repository Mirroring Server in `~/caasp/deployment/openstack/registration.auto.tfvars`:
 +
 Substitute `<CAASP_REGISTRATION_CODE>` for the code from <<registration-code>>.
 +