[v4.9.0] docs(doc-1410): terminology — platform/configure/ + install/ batch 3 (#2130)

platform_versioned_docs/version-4.9.0/configure/advanced/cors-policy.mdx

@@ -17,7 +17,7 @@ Configure Cross-Origin Resource Sharing (CORS) headers at the ingress level so e
 ## Prerequisites
 
 - A deployed vCluster Platform instance with [external access configured](../installation-options/domain.mdx).
-- An ingress controller deployed on the Control Plane Cluster.
+- An ingress controller deployed on the control plane cluster.
 - `helm` v3.10+ and `kubectl` with admin access to the cluster.
 
 ## Overview

platform_versioned_docs/version-4.9.0/configure/agent-settings/customization.mdx

@@ -1,6 +1,6 @@
 ---
-title: Per-host cluster customization
-sidebar_label: Per-Host Cluster Customization
+title: Per-control plane cluster customization
+sidebar_label: Per-Control Plane Cluster Customization
 sidebar_position: 2
 ---
 
@@ -12,11 +12,11 @@ import Input from "@site/src/components/Input";
 import Expander from "@site/src/components/Expander";
 import InterpolatedCodeBlock from "@site/src/components/InterpolatedCodeBlock";
 
-As described in [installation modes][install-modes], the vCluster Platform Agent can be installed using the same `vcluster-platform` chart by setting `agentOnly: true`. The configuration of the agent by default will be decided by the configuration of the platform in the primary host cluster and the `agentValues` content.
+As described in [installation modes][install-modes], the vCluster Platform Agent can be installed using the same `vcluster-platform` chart by setting `agentOnly: true`. The configuration of the agent by default will be decided by the configuration of the platform in the primary control plane cluster and the `agentValues` content.
 
 [install-modes]: ../installation-options/overview#installation-modes
 
-However, this means that all host clusters connecting to the platform will share the same configuration. If different connected host clusters require different agent configurations, there are two supported approaches.
+However, this means that all control plane clusters connecting to the platform will share the same configuration. If different connected control plane clusters require different agent configurations, there are two supported approaches.
 
 ## `loft.sh/agent-values` annotation {#loftsh-annotations}
 Add the `loft.sh/agent-values` annotation to a specific Cluster resource (via the UI or YAML). This annotation overrides the platform-level `agentValues`. The override applies only to the annotated Cluster. For example:
@@ -28,7 +28,7 @@ Add the `loft.sh/agent-values` annotation to a specific Cluster resource (via th
         memory: 2Gi
   ```
 ## Override values
-When installing the agent directly on a host cluster, you can override values by passing a custom values file to Helm. But first, you should tell vCluster Platform to ignore the agent of the specific cluster by adding annotation:
+When installing the agent directly on a control plane cluster, you can override values by passing a custom values file to Helm. But first, you should tell vCluster Platform to ignore the agent of the specific cluster by adding annotation:
 ```
 kubectl annotate cluster cluster-B loft.sh/cluster-ignore-agent="true"
 ```
@@ -40,7 +40,7 @@ helm install vcluster-platform vcluster-platform \
 --values custom-values.yaml
 ```
 <!-- vale on -->
-This approach allows full control over agent configuration at installation time for that specific host cluster.
+This approach allows full control over agent configuration at installation time for that specific control plane cluster.
 
 You can also update the agent settings in vCluster Platform UI.
 <Flow id="cluster-extravalues-vcluster-platform-agent">

platform_versioned_docs/version-4.9.0/configure/agent-settings/least-privilege-mode.mdx

@@ -3,7 +3,7 @@ title: Least Privilege Mode
 sidebar_label: Least Privilege Mode
 sidebar_position: 5
 sidebar_class_name: pro
-description: Reduce the permissions granted to vCluster Platform Agents on connected host clusters by disabling features that aren't required.
+description: Reduce the permissions granted to vCluster Platform Agents on connected control plane clusters by disabling features that aren't required.
 ---
 
 import FeatureTable from '@site/src/components/FeatureTable';
@@ -15,7 +15,7 @@ By default, to minimize operational overhead, the **vCluster Platform Agent** re
 If your organization follows strict RBAC policies, **Least Privilege Mode** can be used to limit the **vCluster Platform Agent** permissions only to your deployment needs.
 
 :::important Scope
-**Least Privilege Mode** applies only to agents deployed on **external host clusters**. It does **not** apply to the agent running in the cluster where the platform is installed.
+**Least Privilege Mode** applies only to agents deployed on **external control plane clusters**. It does **not** apply to the agent running in the cluster where the platform is installed.
 :::
 
 :::important Agent Upgrades
@@ -33,11 +33,11 @@ See [**Self-managed agents / Disable agent upgrades**](agent-upgrade.mdx#disable
 The following configuration options are available:
  - **Feature toggles** - Enable/disable toggles for the features that should be supported by the agent (ClusterAccess, ProjectQuotas, Secrets, SleepMode).
  - **Cluster scope permissions** – Controls the cluster scope permissions granted to the vCluster Platform Agent. Permissions can be extended to accommodate permissions for custom resources.
- - **Managed namespaces scope permissions** – Controls the permissions granted to the vCluster Platform Agent into the namespaces where virtual cluster instances are installed.
+ - **Managed namespaces scope permissions** – Controls the permissions granted to the vCluster Platform Agent into the namespaces where tenant cluster instances are installed.
 
 When a feature toggle is disabled, the corresponding permissions will not be requested and the internal Kubernetes controllers will not be started.
 
-Requests for the disabled features will not be fulfilled. For example, if the ProjectQuotas feature is disabled, the project quotas will not be enforced for the virtual cluster instances deployed on the connected cluster.
+Requests for the disabled features will not be fulfilled. For example, if the ProjectQuotas feature is disabled, the project quotas will not be enforced for the tenant cluster instances deployed on the connected cluster.
 
 See the [Configuration reference](#configuration-reference) section for feature specific disabled state handling.
 
@@ -96,7 +96,7 @@ agentValues:
         ##### `enabled` <span className="config-field-type">boolean</span> <span className="config-field-default">true</span> <span className="config-field-enum"></span>
         Controls whether the agent supports the vCluster Platform **Project Quotas** feature.
       </summary>
-      If set to `false`, project quotas will not be enforced for the virtual cluster instances deployed on the connected cluster.
+      If set to `false`, project quotas will not be enforced for the tenant cluster instances deployed on the connected cluster.
     </details>
   </details>
   <details className="config-field" data-expandable="true">
@@ -122,7 +122,7 @@ agentValues:
         ##### `enabled` <span className="config-field-type">boolean</span> <span className="config-field-default">true</span> <span className="config-field-enum"></span>
         Controls whether the agent supports the vCluster Platform **SleepMode** feature.
       </summary>
-      If set to `false`, sleep/auto-sleep/wake actions will be ignored for the virtual cluster instances deployed on the connected cluster.
+      If set to `false`, sleep/auto-sleep/wake actions will be ignored for the tenant cluster instances deployed on the connected cluster.
     </details>
   </details>
   <details className="config-field" data-expandable="true">
@@ -168,8 +168,8 @@ agentValues:
       Managed namespace admin configuration
     </summary>
 
-    The vCluster Platform Agent namespace-admin Role provides permissions to allow the agent to manage virtual cluster instances within a managed namespace, without cluster-admin level permissions.
-    As part of the virtual cluster instances reconciliation loop, the namespace-admin role is created in the managed namespace and assigned to the vCluster Platform Agent service account.
+    The vCluster Platform Agent namespace-admin Role provides permissions to allow the agent to manage tenant cluster instances within a managed namespace, without cluster-admin level permissions.
+    As part of the tenant cluster instances reconciliation loop, the namespace-admin role is created in the managed namespace and assigned to the vCluster Platform Agent service account.
 
     <details className="config-field" data-expandable="true" open>
       <summary>
@@ -182,7 +182,7 @@ agentValues:
     <details className="config-field" data-expandable="true">
       <summary>
         ##### `extraRules` <span className="config-field-type">object[]</span> <span className="config-field-default"></span> <span className="config-field-enum"></span>
-        Allows granting additional permissions to the vCluster Platform Agent within the managed namespaces where virtual cluster instances are installed.
+        Allows granting additional permissions to the vCluster Platform Agent within the managed namespaces where tenant cluster instances are installed.
       </summary>
 
       ```yaml title="platform.yaml"
@@ -231,7 +231,7 @@ A typical rollout looks like this:
 1. Confirm that the vCluster Platform managed [agent upgrades](agent-upgrade.mdx#disable-agent-upgrades) is disabled for the connected clusters.
 2. Enable **Least Privilege Mode** and **disable** all optional features.
 3. Verify deployment:
-   - Confirm that virtual cluster instances can be deployed as expected.
+   - Confirm that tenant cluster instances can be deployed as expected.
    - Validate deployment compliance with your organization's policies.
 4. Enable required features one by one and repeat the verification steps.
 5. Test agent behavior in a non-production environment.
@@ -248,6 +248,6 @@ A typical rollout looks like this:
 If the agent stops working after enabling **Least Privilege Mode**:
 
 - Review agent logs for RBAC permission errors. `agentValues.env.KUBERNETES_VERBOSITY_LEVEL: "4"` option can be used to gain visibility into the vCluster Platform Agent Kubernetes API requests.
-- Confirm that you are applying this only to the agents running on external host clusters
+- Confirm that you are applying this only to the agents running on external control plane clusters
 
 If you need more help troubleshooting agent behavior, see [Troubleshooting](troubleshooting.mdx).

platform_versioned_docs/version-4.9.0/configure/agent-settings/overview.mdx

@@ -25,19 +25,19 @@ import ConnectPlatform from '../../_fragments/cli-steps/connect-platform.mdx';
 
 
 # Overview
-When a **vCluster Platform** is deployed on a host cluster (or, primary host cluster), it can act as a centralized control plane. Other host clusters can connect to the vCluster Platform running on the primary host cluster and be managed by it. In this architecture:
-- The primary host cluster runs the vCluster Platform.
-- Other host clusters connect to the primary host cluster and run the vCluster Platform Agent.
-- The Platform coordinates and manages all connected host clusters through their agents.
-- There are both vCluster Platform and vCluster Platform agent running on the primary host cluster. The vCluster Platform manages the primary host cluster through its vCluster Platform Agent as well.
+When a **vCluster Platform** is deployed on a control plane cluster (or, primary control plane cluster), it can act as a centralized control plane. Other control plane clusters can connect to the vCluster Platform running on the primary control plane cluster and be managed by it. In this architecture:
+- The primary control plane cluster runs the vCluster Platform.
+- Other control plane clusters connect to the primary control plane cluster and run the vCluster Platform Agent.
+- The Platform coordinates and manages all connected control plane clusters through their agents.
+- There are both vCluster Platform and vCluster Platform agent running on the primary control plane cluster. The vCluster Platform manages the primary control plane cluster through its vCluster Platform Agent as well.
 
-Agent settings are the content in the [`values.yaml`](../introduction.mdx) under the `agentValues`. It controls the behavior of vCluster Platform Agents installed in the host clusters 
+Agent settings are the content in the [`values.yaml`](../introduction.mdx) under the `agentValues`. It controls the behavior of vCluster Platform Agents installed in the control plane clusters 
 that are managed by the vCluster Platform.
 
 The `agentValues` behavior is as follows:
 - By default, `agentValues` is an empty object `{}`.
-- An empty `agentValues` object means that agents installed on connected host clusters will inherit the same configuration as the platform running on the primary host cluster.
-- You can populate `agentValues` to override the default agent configuration globally for all connected host clusters.
+- An empty `agentValues` object means that agents installed on connected control plane clusters will inherit the same configuration as the platform running on the primary control plane cluster.
+- You can populate `agentValues` to override the default agent configuration globally for all connected control plane clusters.
 
 ## Connect to platform {#connect-to-platform}
 A new cluster can be connected to the platform through the UI or CLI:

platform_versioned_docs/version-4.9.0/configure/agent-settings/security-context.mdx

@@ -78,7 +78,7 @@ agentValues:
 ```
 
 #### Cluster-specific security context
-As mentioned [here](customization.mdx), you can customize the agent in each connected host cluster independently.
+As mentioned [here](customization.mdx), you can customize the agent in each connected control plane cluster independently.
 
 To achieve cluster-specific security context, you can override security contexts for specific clusters using the [`loft.sh/agent-values` annotation](overview#loftsh-annotations):
 

platform_versioned_docs/version-4.9.0/configure/installation-options/overview.mdx

@@ -9,7 +9,7 @@ Installation options are the content in the [`values.yaml`](../introduction.mdx)
 It contains fields like `resources`, `replicas`, `ingress` and also custom fields like `admin`, `product`, `agentOnly`.
 
 You set values of installation options to customize the deployment of vCluster Platform. These installation options are not available in the vCluster Platform UI after the vCluster Platform 
-is installed in the host cluster but can only be [applied using `helm`](../introduction#applying-configuration) before the deployment.
+is installed in the control plane cluster but can only be [applied using `helm`](../introduction#applying-configuration) before the deployment.
 
 ## Installation modes
 

platform_versioned_docs/version-4.9.0/configure/platform-configs/audit.mdx

@@ -19,8 +19,8 @@ Audit logging in the platform provides a security-relevant, chronological set of
 
 The platform can log activities related to:
 
-- Management instance changes, such as creation of new virtual clusters, spaces, etc.
-- Changes within a virtual cluster or space
+- Management instance changes, such as creation of new tenant clusters, spaces, etc.
+- Changes within a tenant cluster or space
 - Changes within a connected cluster
 
 Auditing in the platform is similar to [auditing Kubernetes clusters](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) in general.
@@ -62,7 +62,7 @@ The audit logging feature increases the memory consumption of the platform becau
 The platform provides audit levels, which are preconfigured audit policies for the most common use cases. These levels range from 1 to 4 where 1 logs the fewest requests, while 4 logs the most:
 
 - **Level 1**: Logs modifying requests such as creation / modification or deletion of any objects
-- **Level 2**: Like Level 1 but also logs the metadata of reading requests, such as listing pods inside a virtual cluster or space. It won't log the response or request payload and instead only the metadata such as request origin, target, etc.
+- **Level 2**: Like Level 1 but also logs the metadata of reading requests, such as listing pods inside a tenant cluster or space. It won't log the response or request payload and instead only the metadata such as request origin, target, etc.
 - **Level 3**: Like Level 2 but instead of only logging the request metadata also logs the complete request payload sent to the platform
 - **Level 4**: Like Level 3 but instead of only logging metadata and request payload, also logs the response the platform has sent to the requester
 

platform_versioned_docs/version-4.9.0/configure/platform-configs/cost-control.mdx

@@ -7,12 +7,12 @@ description: Learn how to configure the Cost Control Dashboard and its supportin
 
 import VersionBadge from '@site/src/components/VersionBadge';
 
-The platform comes with the cost control dashboard enabled by default, offering insights into potential [cost savings](https://www.vcluster.com/cost-savings) through virtual clusters.
+The platform comes with the cost control dashboard enabled by default, offering insights into potential [cost savings](https://www.vcluster.com/cost-savings) through tenant clusters.
 
 <VersionBadge platformVersion="v4.2.0" vclusterVersion="v0.22.0"/>
 
 To track allocations and calculate savings for workloads running inside
-virtual clusters the platform deploys and manages [Prometheus](https://prometheus.io/) and
+tenant clusters the platform deploys and manages [Prometheus](https://prometheus.io/) and
 [OpenCost](https://www.opencost.io/) on each connected cluster. Prometheus uses a time series database that requires
 persistent volume storage to retain metrics over time. The platform-managed
 Prometheus is configured to collect the minimum metrics required for the cost