diff --git a/docs/intro-replicated.mdx b/docs/intro-replicated.mdx index 41c955523e..111a4409b5 100644 --- a/docs/intro-replicated.mdx +++ b/docs/intro-replicated.mdx @@ -27,7 +27,7 @@ The following diagram demonstrates the process of using the Replicated Platform [View a larger version of this image](/images/replicated-platform.png) -The diagram above shows an application that is packaged with the [**Replicated SDK**](/vendor/replicated-sdk-overview). The application is tested in clusters provisioned with the [**Replicated Compatibility Matrix**](/vendor/testing-about), then added to a new release in the [**Vendor Portal**](/vendor/releases-about) using an automated CI/CD pipeline. +The diagram above shows an application that is packaged with the [**Replicated SDK**](/vendor/replicated-sdk-overview). The application is tested in clusters provisioned with the [**Replicated Compatibility Matrix (CMX)**](/vendor/testing-about), then added to a new release in the [**Vendor Portal**](/vendor/releases-about) using an automated CI/CD pipeline. The application is then installed by a customer ("Big Bank") on a VM. To install, the customer downloads their license, which grants proxy access to the application images through the [**Replicated proxy registry**](/vendor/private-images-about). They also download the installation assets for the [**Replicated Embedded Cluster**](/vendor/embedded-overview) installer. @@ -101,11 +101,11 @@ The following shows an example of the Enterprise Portal dashboard: ### Compatibility Matrix -Replicated Compatibility Matrix can be used to create VMs or Kubernetes clusters within minutes or less. You can interact with Compatibility Matrix through the Vendor Portal or the Replicated CLI, making it possible to integrate Compatibility Matrix into your existing CI/CD workflows to programmatically create test environments. +Replicated Compatibility Matrix (CMX) can be used to create VMs or Kubernetes clusters within minutes or less. You can interact with CMX through the Vendor Portal or the Replicated CLI, making it possible to integrate CMX into your existing CI/CD workflows to programmatically create test environments. -For more information, see [About Compatibility Matrix](/vendor/testing-about). +For more information, see [About CMX](/vendor/testing-about). -The following shows the Compatibility Matrix page for creating a cluster: +The following shows the CMX page for creating a cluster: Create a cluster page @@ -143,9 +143,9 @@ For more information about using the Replicated SDK, see [About the Replicated S ### Test -The Compatibility Matrix can be used to quickly provision ephemeral VMs and Kubernetes clusters. When integrated into existing CI/CD workflows, the Compatibility Matrix can be used to automatically create a variety of customer-representative environments for testing code changes. +The CMX can be used to quickly provision ephemeral VMs and Kubernetes clusters. When integrated into existing CI/CD workflows, the CMX can be used to automatically create a variety of customer-representative environments for testing code changes. -For more information, see [About Compatibility Matrix](/vendor/testing-about). +For more information, see [About CMX](/vendor/testing-about). ### License @@ -186,5 +186,5 @@ ISVs can also set up email and Slack notifications to get alerted of important i Support teams can use Replicated features to more quickly diagnose and resolve application issues. For example: - Customize and generate support bundles, which collect and analyze redacted information from the customer's cluster, environment, and application instance. See [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about). -- Provision customer-representative environments with Compatibility Matrix to recreate and diagnose issues. See [About Compatibility Matrix](/vendor/testing-about). +- Provision customer-representative environments with CMX to recreate and diagnose issues. See [About CMX](/vendor/testing-about). - Get insights into an instance's status by accessing telemetry data, which covers the health of the application, the current application version, and details about the infrastructure and cluster where the application is running. For more information, see [Customer Reporting](/vendor/customer-reporting). For more information, see [Customer Reporting](/vendor/customer-reporting). diff --git a/docs/partials/ci-cd/_test-recs.mdx b/docs/partials/ci-cd/_test-recs.mdx index 31b25be58d..7accc87a94 100644 --- a/docs/partials/ci-cd/_test-recs.mdx +++ b/docs/partials/ci-cd/_test-recs.mdx @@ -1,9 +1,9 @@ -* **Application Testing:** Traditional application testing includes unit, integration, and end-to-end tests. These tests are critical for application reliability, and Compatibility Matrix is designed to to incorporate and use your application testing. +* **Application Testing:** Traditional application testing includes unit, integration, and end-to-end tests. These tests are critical for application reliability, and CMX is designed to to incorporate and use your application testing. * **Performance Testing:** Performance testing is used to benchmark your application to ensure it can handle the expected load and scale gracefully. Test your application under a range of workloads and scenarios to identify any bottlenecks or performance issues. Make sure to optimize your application for different Kubernetes distributions and configurations by creating all of the environments you need to test in. * **Smoke Testing:** Using a single, conformant Kubernetes distribution to test basic functionality of your application with default (or standard) configuration values is a quick way to get feedback if something is likely to be broken for all or most customers. Replicated also recommends that you include each Kubernetes version that you intend to support in your smoke tests. -* **Compatibility Testing:** Because applications run on various Kubernetes distributions and configurations, it is important to test compatibility across different environments. Compatibility Matrix provides this infrastructure. +* **Compatibility Testing:** Because applications run on various Kubernetes distributions and configurations, it is important to test compatibility across different environments. CMX provides this infrastructure. -* **Canary Testing:** Before releasing to all customers, consider deploying your application to a small subset of your customer base as a _canary_ release. This lets you monitor the application's performance and stability in real-world environments, while minimizing the impact of potential issues. Compatibility Matrix enables canary testing by simulating exact (or near) customer environments and configurations to test your application with. \ No newline at end of file +* **Canary Testing:** Before releasing to all customers, consider deploying your application to a small subset of your customer base as a _canary_ release. This lets you monitor the application's performance and stability in real-world environments, while minimizing the impact of potential issues. CMX enables canary testing by simulating exact (or near) customer environments and configurations to test your application with. \ No newline at end of file diff --git a/docs/vendor/ci-overview.md b/docs/vendor/ci-overview.md index adf01ed55d..42ffa426ba 100644 --- a/docs/vendor/ci-overview.md +++ b/docs/vendor/ci-overview.md @@ -16,9 +16,9 @@ The following are Replicated's best practices and recommendations for CI/CD: * Include unique workflows for development and for releasing your application. This allows you to run tests on every commit, and then to promote releases to internal and customer-facing channels only when ready. For more information about the workflows that Replicated recommends, see [Recommended CI/CD Workflows](ci-workflows). -* Integrate Replicated Compatibility Matrix into your CI/CD workflows to quickly create multiple different types of clusters where you can deploy and test your application. Supported distributions include OpenShift, GKE, EKS, and more. For more information, see [About Compatibility Matrix](testing-about). +* Integrate Replicated Compatibility Matrix (CMX) into your CI/CD workflows to quickly create multiple different types of clusters where you can deploy and test your application. Supported distributions include OpenShift, GKE, EKS, and more. For more information, see [About CMX](testing-about). -* If you use the GitHub Actions CI/CD platform, integrate the custom GitHub actions that Replicated maintains to replace repetitive tasks related to distributing application with Replicated or using Compatibility Matrix. For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-workflows-github-actions). +* If you use the GitHub Actions CI/CD platform, integrate the custom GitHub actions that Replicated maintains to replace repetitive tasks related to distributing application with Replicated or using CMX. For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-workflows-github-actions). * To help show you are conforming to a secure supply chain, sign all commits and container images. Additionally, provide a verification mechanism for container images. diff --git a/docs/vendor/ci-workflows-github-actions.md b/docs/vendor/ci-workflows-github-actions.md index 59a6a418a3..6634b03371 100644 --- a/docs/vendor/ci-workflows-github-actions.md +++ b/docs/vendor/ci-workflows-github-actions.md @@ -4,7 +4,7 @@ This topic describes how to integrate Replicated's custom GitHub actions into co ## Overview -Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to distributing your application with Replicated and related to using the Compatibility Matrix, such as: +Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to distributing your application with Replicated and related to using Replicated Compatibility Matrix (CMX), such as: * Creating and removing customers, channels, and clusters * Promoting releases * Creating a matrix of clusters for testing based on the Kubernetes distributions and versions where your customers are running application instances @@ -119,7 +119,7 @@ For an up-to-date list of the avilable custom GitHub actions, see the [replicate report-compatibility-result - In development or release workflows, use this action to report the success or failure of tests that ran in clusters provisioned by the Compatibility Matrix. + In development or release workflows, use this action to report the success or failure of tests that ran in clusters provisioned by CMX. release compatibility diff --git a/docs/vendor/ci-workflows.mdx b/docs/vendor/ci-workflows.mdx index a2eb656b33..99bc5f1706 100644 --- a/docs/vendor/ci-workflows.mdx +++ b/docs/vendor/ci-workflows.mdx @@ -6,7 +6,7 @@ This topic provides Replicated's recommended development and release workflows f ## Overview -Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). The development and release workflows in this topic describe the recommended steps and jobs to include in your own workflows, including how to integrate Replicated Compatibility Matrix into your workflows for testing. For more information about Compatibility Matrix, see [About Compatibility Matrix](testing-about). +Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). The development and release workflows in this topic describe the recommended steps and jobs to include in your own workflows, including how to integrate Replicated Compatibility Matrix (CMX) into your workflows for testing. For more information about CMX, see [About CMX](testing-about). For each step, the corresponding Replicated CLI command is provided. Additionally, for users of the GitHub Actions platform, a corresponding custom GitHub action that is maintained by Replicated is also provided. For more information about using the Replicated CLI, see [Install the Replicated CLI](/reference/replicated-cli-installing). For more information about the Replicated GitHub actions, see [Use Replicated GitHub Actions in CI/CD](ci-workflows-github-actions). @@ -64,11 +64,11 @@ jobs: ### Prepare clusters, deploy, and test {#dev-deploy} -Add a job with the following steps to prepare clusters with Replicated Compatibility Matrix, deploy the application, and run tests: +Add a job with the following steps to prepare clusters with CMX, deploy the application, and run tests: -1. Use Replicated Compatibility Matrix to prepare one or more clusters and deploy the application. Consider the following recommendations: +1. Use CMX to prepare one or more clusters and deploy the application. Consider the following recommendations: - * For development workflows, Replicated recommends that you use the `cluster prepare` command to provision one or more clusters with Compatibility Matrix. The `cluster prepare` command creates a cluster, creates a release, and installs the release in the cluster, without the need to promote the release to a channel or create a temporary customer. See the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) Replicated CLI command. Or, for GitHub Actions workflows, see the [prepare-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/prepare-cluster) GitHub action. + * For development workflows, Replicated recommends that you use the `cluster prepare` command to provision one or more clusters with CMX. The `cluster prepare` command creates a cluster, creates a release, and installs the release in the cluster, without the need to promote the release to a channel or create a temporary customer. See the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) Replicated CLI command. Or, for GitHub Actions workflows, see the [prepare-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/prepare-cluster) GitHub action. :::note The `cluster prepare` command is Beta. It is recommended for development only and is not recommended for production releases. For production releases, Replicated recommends that you use the `cluster create` command instead. For more information, see [Create cluster matrix and deploy](#rel-deploy) in _Release Workflow_ below. @@ -80,13 +80,13 @@ Add a job with the following steps to prepare clusters with Replicated Compatibi 1. After the tests complete, remove the cluster. Alternatively, if you used the `--ttl` flag with the `cluster prepare` command, the cluster is automatically removed when the time period provided is reached. See the [`cluster remove`](/reference/replicated-cli-cluster-prepare) Replicated CLI command. Or, for GitHub Actions workflows, see the [remove-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/remove-cluster) action. -## Compatibility Matrix-Only Development Workflow +## CMX-Only Development Workflow In a development workflow (which runs multiple times per day and is triggered by a commit to the application code repository), the source code is built and the application is deployed to clusters for testing. This example development workflow does _not_ create releases or customers in the Replicated vendor platform. This workflow is useful for applications that are not distributed or managed in the Replicated platform. -The following describes the recommended steps to include in a development workflow using Compatibility Matrix: +The following describes the recommended steps to include in a development workflow using CMX: 1. [Define workflow triggers](#dev-triggers) 1. [Build source code](#dev-build) @@ -120,9 +120,9 @@ jobs: ### Create cluster matrix, deploy, and test {#dev-deploy} -Add a job with the following steps to provision clusters with Compatibility Matrix, deploy your application to the clusters, and run tests: +Add a job with the following steps to provision clusters with CMX, deploy your application to the clusters, and run tests: -1. Use Compatibility Matrix to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action. +1. Use CMX to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action. The following example shows creating a matrix of clusters of different distributions and versions using GitHub Actions: @@ -141,7 +141,7 @@ Add a job with the following steps to provision clusters with Compatibility Matr - {distribution: openshift, version: "4.13.0-okd"} ``` -1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with Compatibility Matrix, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig). +1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with CMX, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig). 1. Run tests, such as integration, smoke, and canary tests. For more information about recommended types of tests to run, see [Best Practices and Recommendations](/vendor/ci-overview#best-practices-and-recommendations) in _About Integrating with CI/CD_. @@ -242,11 +242,11 @@ Consider the following requirements and recommendations: ### Create cluster matrix, deploy, and test {#rel-deploy} -Add a job with the following steps to provision clusters with Compatibility Matrix, deploy the release to the clusters, and run tests: +Add a job with the following steps to provision clusters with CMX, deploy the release to the clusters, and run tests: 1. Create a temporary customer for installing the release. See the [customer create](/reference/replicated-cli-customer-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-customer](https://github.com/replicatedhq/replicated-actions/tree/main/create-customer) action. -1. Use Compatibility Matrix to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action. +1. Use CMX to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action. Consider the following recommendations: @@ -273,7 +273,7 @@ Add a job with the following steps to provision clusters with Compatibility Matr - {distribution: openshift, version: "4.13.0-okd"} ``` -1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with Compatibility Matrix, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig). +1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with CMX, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig). For more information about installing in an existing cluster, see: * [Installing with Helm](/vendor/install-with-helm) diff --git a/docs/vendor/compatibility-matrix-usage.md b/docs/vendor/compatibility-matrix-usage.md index 5e7e6d9cfc..0585e5f535 100644 --- a/docs/vendor/compatibility-matrix-usage.md +++ b/docs/vendor/compatibility-matrix-usage.md @@ -1,6 +1,6 @@ -# Compatibility Matrix Usage History +# CMX Usage History This topic describes using the Replicated Vendor Portal to understand -Compatibility Matrix usage across your team. +Replicated Compatibility Matrix (CMX) usage across your team. ## View Historical Usage The **Compatibility Matrix > History** page provides @@ -57,7 +57,7 @@ To filter by a specific field, click on the filter icon in the column header, th ## Get Usage History with the Vendor API v3 -For more information about using the Vendor API v3 to get Compatibility Matrix +For more information about using the Vendor API v3 to get CMX usage history information, see the following API endpoints within the Vendor API v3 documentation: @@ -69,7 +69,7 @@ Vendor API v3 documentation: For examples of using these endpoints, see the sections below. ### Credit Balance and Summarized Usage -You can use the `/v3/cmx/stats` endpoint to get summarized usage information in addition to your Compatibility Matrix +You can use the `/v3/cmx/stats` endpoint to get summarized usage information in addition to your CMX credit balance. This endpoint returns: diff --git a/docs/vendor/kots-faq.mdx b/docs/vendor/kots-faq.mdx index 21cf0704e3..d62544127b 100644 --- a/docs/vendor/kots-faq.mdx +++ b/docs/vendor/kots-faq.mdx @@ -67,19 +67,19 @@ For more information about the Replicated features that enhance each phase of th ### What types of clusters can I create with Compatibility Matrix? -You can use Compatibility Matrix to get kubectl access to running clusters within minutes or less. Compatibility Matrix supports a variety of VM and cloud distributions, including Red Hat OpenShift, Replicated Embedded Cluster, and Oracle Container Engine for Kubernetes (OKE). For a complete list, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters). +You can use Compatibility Matrix (CMX)to get kubectl access to running clusters within minutes or less. CMX supports a variety of VM and cloud distributions, including Red Hat OpenShift, Replicated Embedded Cluster, and Oracle Container Engine for Kubernetes (OKE). For a complete list, see [Supported CMX Cluster Types](/vendor/testing-supported-clusters). ### How does billing work? -Clusters created with Compatibility Matrix are billed by the minute. Per-minute billing begins when the cluster reaches a running status and ends when the cluster is deleted. For more information, see [Billing and Credits](/vendor/testing-about#billing-and-credits). +Clusters created with CMX are billed by the minute. Per-minute billing begins when the cluster reaches a running status and ends when the cluster is deleted. For more information, see [Billing and Credits](/vendor/testing-about#billing-and-credits). ### How do I buy credits? -To create clusters with Compatibility Matrix, you must have credits in your Vendor Portal account. If you have a contract, you can purchase credits by logging in to the Vendor Portal and going to **[Compatibility Matrix > Buy additional credits](https://vendor.replicated.com/compatibility-matrix)**. Otherwise, to request credits, log in to the Vendor Portal and go to **[Compatibility Matrix > Request more credits](https://vendor.replicated.com/compatibility-matrix)**. +To create clusters with CMX, you must have credits in your Vendor Portal account. If you have a contract, you can purchase credits by logging in to the Vendor Portal and going to **[Compatibility Matrix > Buy additional credits](https://vendor.replicated.com/compatibility-matrix)**. Otherwise, to request credits, log in to the Vendor Portal and go to **[Compatibility Matrix > Request more credits](https://vendor.replicated.com/compatibility-matrix)**. ### How do I add Comaptibility Matrix to my CI/CD pipelines? -You can use Replicated CLI commands to integrate Compatibility Matrix into your CI/CD development and production workflows. This allows you to programmatically create multiple different types of clusters where you can deploy and test your application before releasing. +You can use Replicated CLI commands to integrate CMX into your CI/CD development and production workflows. This allows you to programmatically create multiple different types of clusters where you can deploy and test your application before releasing. For more information, see [About Integrating with CI/CD](/vendor/ci-overview). diff --git a/docs/vendor/quick-start.mdx b/docs/vendor/quick-start.mdx index 4f80ff37cc..96670ab93f 100644 --- a/docs/vendor/quick-start.mdx +++ b/docs/vendor/quick-start.mdx @@ -37,17 +37,17 @@ Before you begin, do the following to set up your environment: * Ensure that you have access to a VM that meets the requirements for Embedded Cluster: - * **Option 1: Use Compatibility Matrix.** To use Replicated Compatibility Matrix to create a VM, do the following before proceeding: + * **Option 1: Use Compatibility Matrix.** To use Replicated Compatibility Matrix (CMX) to create a VM, do the following before proceeding: - * Request Compatibility Matrix credits. You can request credits by creating a Vendor Portal account and then going to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix) in the Vendor Portal. For more information about creating an account, see [Create a Vendor Account](vendor-portal-creating-account). For more information about Compatibility Matrix credits, see [Billing and Credits](/vendor/testing-about#billing-and-credits). + * Request CMX credits. You can request credits by creating a Vendor Portal account and then going to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix) in the Vendor Portal. For more information about creating an account, see [Create a Vendor Account](vendor-portal-creating-account). For more information about CMX credits, see [Billing and Credits](/vendor/testing-about#billing-and-credits). :::note - If you are new to the Replicated platform, you might be eligible for $100 in free Compatibility Matrix credits. To request your free credits, reach out to our sales team at https://www.replicated.com/contact and note in the comments that you are completing the Replicated Quick Start. + If you are new to the Replicated platform, you might be eligible for $100 in free CMX credits. To request your free credits, reach out to our sales team at https://www.replicated.com/contact and note in the comments that you are completing the Replicated Quick Start. ::: - * Ensure that you have an SSH key in your GitHub account. Then, add your GitHub username to your Vendor Portal [**Account Settings**](https://vendor.replicated.com/account-settings). This will provide SSH access to VMs that you create with Compatibility Matrix. For more information, see [Set Up SSH Access](/vendor/testing-vm-create#set-up-ssh-access) in _Create VMs_. + * Ensure that you have an SSH key in your GitHub account. Then, add your GitHub username to your Vendor Portal [**Account Settings**](https://vendor.replicated.com/account-settings). This will provide SSH access to VMs that you create with CMX. For more information, see [Set Up SSH Access](/vendor/testing-vm-create#set-up-ssh-access) in _Create VMs_. - After you complete the prerequisites above, continue to the [Quick Start](#quick-start). You will create the VM with Compatibility Matrix as part of the tutorial. + After you complete the prerequisites above, continue to the [Quick Start](#quick-start). You will create the VM with CMX as part of the tutorial. * **Option 2: Bring your own VM.** Your VM must meet these requirements: @@ -276,7 +276,7 @@ Before you begin, do the following to set up your environment: 1. (Optional) In the Vendor Portal, click **Releases** to view the release that you promoted. In the release viewer, you can see the Replicated manifests as well as the SlackerNews `Chart.yaml` and `values.yaml` files. -1. If you brought your own VM, SSH onto your VM. Otherwise, follow these steps to create and SSH onto a VM with Compatibility Matrix: +1. If you brought your own VM, SSH onto your VM. Otherwise, follow these steps to create and SSH onto a VM with CMX: 1. Create an Ubuntu VM that expires after two hours: @@ -300,7 +300,7 @@ Before you begin, do the following to set up your environment: 97940819 practical_black ubuntu 24.04 running c726ffff 2025-08-20 14:32 MDT 2025-08-20 16:33 MDT $0.69 ``` - 1. Run the following command to use the Compatibility Matrix Forwarder to SSH onto the VM: + 1. Run the following command to use the CMX Forwarder to SSH onto the VM: ```bash ssh VM_ID@replicatedvm.com @@ -311,7 +311,7 @@ Before you begin, do the following to set up your environment: If you are prompted to add the fingerprint for replicatedvm.com, type `yes` and press Enter. ::: - 1. When prompted, provide the passphrase for the SSH key in your linked GitHub account. Compatibility Matrix uses GitHub SSH to provide access to the VM. + 1. When prompted, provide the passphrase for the SSH key in your linked GitHub account. CMX uses GitHub SSH to provide access to the VM. 1. Install the application with Embedded Cluster: @@ -363,7 +363,7 @@ Before you begin, do the following to set up your environment: :::note The IP address in the provided URL might be the private IP address of your VM. You might need to edit the URL to use the public IP address. ::: - * If you created the VM with Compatibility Matrix: + * If you created the VM with CMX: 1. In the Vendor Portal, go to [**Compatibility Matrix**](https://vendor.replicated.com/compatibility-matrix/overview). 1. Open the dot menu for your VM and click **Edit VM**. @@ -392,7 +392,7 @@ Before you begin, do the following to set up your environment: 1. On the **Certificate type** screen, either select **Self-signed** to continue using the self-signed Admin Console certificate or click **Upload your own** to upload your own private key and certificate. By default, a self-signed TLS certificate is used to secure communication between your browser and the Admin Console. You will see a warning in your browser every time you access the Admin Console unless you upload your own certificate. :::note - If you created the VM with Compatibility Matrix, you might not see these pages. Instead, your browser might automatically redirect to the Admin Console login screen. + If you created the VM with CMX, you might not see these pages. Instead, your browser might automatically redirect to the Admin Console login screen. ::: 1. On the login screen, enter the Admin Console password that you set and click **Log in**. @@ -410,7 +410,7 @@ Before you begin, do the following to set up your environment: 1. On the **Configure SlackerNews** screen, complete the following fields: * For **Ingress Hostname**: - * If you created the VM with Compatibility Matrix, enter the URL that you copied for the DNS record with a target port of 443. For example, `pensive-keldysh.ingress.replicatedcluster.com`. + * If you created the VM with CMX, enter the URL that you copied for the DNS record with a target port of 443. For example, `pensive-keldysh.ingress.replicatedcluster.com`. * If you are using your own VM, provide the public IP address for your VM. You can copy the IP address from your browser's address bar where you are currently accessing the Admin Console. Alternatively, if you have a hostname for your VM's IP address, you can provide that instead. @@ -585,7 +585,7 @@ Before you begin, do the following to set up your environment: 1. Clean up the installation: - * If you created the VM with Compatibility Matrix, delete the VM: + * If you created the VM with CMX, delete the VM: ```bash replicated vm rm VM_ID @@ -622,7 +622,7 @@ To get started, see [Onboard to the Replicated Platform](replicated-onboarding). For more information about the Replicated Platform features mentioned in this quick start, see: * [Embedded Cluster Overview](/vendor/embedded-overview) -* [About Compatibility Matrix](/vendor/testing-about) +* [About CMX](/vendor/testing-about) * [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about) * [About the Replicated SDK](/vendor/replicated-sdk-overview) * [Manage Releases with the CLI](/vendor/releases-creating-cli) diff --git a/docs/vendor/replicated-onboarding.mdx b/docs/vendor/replicated-onboarding.mdx index 1dfba494e9..3c7257626c 100644 --- a/docs/vendor/replicated-onboarding.mdx +++ b/docs/vendor/replicated-onboarding.mdx @@ -613,11 +613,11 @@ For more information, see [Configure Custom Metrics](/vendor/custom-metrics). ### Integrate with CI/CD -Replicated recommends that teams integrate the Replicated Platform into their existing develeopment and production CI/CD workflows. This can be useful for automating the processes of creating new releases, promoting releases, and testing releases with the Replicated Compatibility Matrix. +Replicated recommends that teams integrate the Replicated Platform into their existing develeopment and production CI/CD workflows. This can be useful for automating the processes of creating new releases, promoting releases, and testing releases with the Replicated Compatibility Matrix (CMX). For more information, see: * [About Integrating with CI/CD](/vendor/ci-overview) -* [About Compatibility Matrix](/vendor/testing-about) +* [About CMX](/vendor/testing-about) * [Recommended CI/CD Workflows](/vendor/ci-workflows) ### Customize Release Channels diff --git a/docs/vendor/testing-about.md b/docs/vendor/testing-about.md index 145e7bf31f..3c5292629c 100644 --- a/docs/vendor/testing-about.md +++ b/docs/vendor/testing-about.md @@ -1,21 +1,21 @@ -# About Compatibility Matrix +# About CMX -This topic describes Replicated Compatibility Matrix, including use cases, billing, limitations, and more. +This topic describes Replicated Compatibility Matrix (CMX), including use cases, billing, limitations, and more. ## Overview -You can use Replicated Compatibility Matrix to quickly provision ephemeral clusters and VMs. Compatibility Matrix's networking features also provide kubectl or SSH access to clusters and VMs. This allows you to install and test your application in a range of different development environments before releasing to customers. +You can use CMX to quickly provision ephemeral clusters and VMs. CMX's networking features also provide kubectl or SSH access to clusters and VMs. This allows you to install and test your application in a range of different development environments before releasing to customers. -Example use cases for Compatibility Matrix include: +Example use cases for CMX include: * Run tests before releasing a new version of your application to validate compatibility with supported Kubernetes distributions * Get access to a cluster or VM to develop on and quickly test changes * Reproduce a reported issue on a customer-representative environment for troubleshooting -You can use Compatibility Matrix with the Replicated CLI or the Replicated Vendor Portal. For more information about how to use Compatibility Matrix, see [Create and Manage Clusters](testing-how-to) and [Create VMs](testing-vm-create). +You can use CMX with the Replicated CLI or the Replicated Vendor Portal. For more information about how to use CMX, see [Create and Manage Clusters](testing-how-to) and [Create VMs](testing-vm-create). ## Supported Clusters and VMs -Compatibility Matrix can create VMs, VM-based clusters (such as kind, k3s, RKE2, and Red Hat OpenShift OKD), and cloud-managed clusters (such as EKS, GKE and AKS): +CMX can create VMs, VM-based clusters (such as kind, k3s, RKE2, and Red Hat OpenShift OKD), and cloud-managed clusters (such as EKS, GKE and AKS): * Cloud-based Kubernetes distributions are run in a Replicated managed and controlled cloud account to optimize and deliver a clusters quickly and reliably. The Replicated account has control planes ready and adds a node group when you request it, making the cluster available much faster than if you try to create your own cluster with your own cloud account. @@ -23,16 +23,16 @@ Compatibility Matrix can create VMs, VM-based clusters (such as kind, k3s, RKE2, You can run [`replicated cluster versions`](/reference/replicated-cli-cluster-versions) or [`replicated vm versions`](/reference/replicated-cli-vm-versions) for an up-to-date list of the available cluster distributions or VM types. -For more information about the supported cluster distributions, see [Supported Compatibility Matrix Cluster Types](testing-supported-clusters). +For more information about the supported cluster distributions, see [Supported CMX Cluster Types](testing-supported-clusters). For more information about supported VMs, see [Supported VM Types](/vendor/testing-vm-create#supported-vm-types) ## Billing and Credits -Clusters and VMs created with Compatibility Matrix are billed by the minute, plus a startup charge. Per-minute billing begins when a `running` status is reached and ends when the cluster or VM is deleted. +Clusters and VMs created with CMX are billed by the minute, plus a startup charge. Per-minute billing begins when a `running` status is reached and ends when the cluster or VM is deleted. -For more information about pricing, see [Compatibility Matrix Pricing](testing-pricing). +For more information about pricing, see [CMX Pricing](testing-pricing). -To create clusters with Compatibility Matrix, you must have credits in your Vendor Portal account. +To create clusters with CMX, you must have credits in your Vendor Portal account. If you have a contract, you can purchase credits by logging in to the Vendor Portal and going to [**Compatibility Matrix > Buy additional credits**](https://vendor.replicated.com/compatibility-matrix). Otherwise, to request credits, log in to the Vendor Portal and go to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix). \ No newline at end of file diff --git a/docs/vendor/testing-ci-cd.md b/docs/vendor/testing-ci-cd.md index bc0cb479a7..46ab565088 100644 --- a/docs/vendor/testing-ci-cd.md +++ b/docs/vendor/testing-ci-cd.md @@ -1,16 +1,16 @@ import TestRecs from "../partials/ci-cd/_test-recs.mdx" -# Test in Compatibility Matrix with CI/CD +# Test in CMX with CI/CD -This topic describes how to integrate Replicated Compatibility Matrix into your CI/CD workflows. +This topic describes how to integrate Replicated Compatibility Matrix (CMX) into your CI/CD workflows. -## About Using Compatibility Matrix with CI/CD +## About Using CMX with CI/CD -Replicated recommends that you integrate Compatibility Matrix into your existing CI/CD workflow to automate the process of creating clusters to install your application and run tests. For more information, including additional best practices and recommendations for CI/CD, see [About Integrating with CI/CD](/vendor/ci-overview). +Replicated recommends that you integrate CMX into your existing CI/CD workflow to automate the process of creating clusters to install your application and run tests. For more information, including additional best practices and recommendations for CI/CD, see [About Integrating with CI/CD](/vendor/ci-overview). ### Replicated GitHub Actions -Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to using Compatibility Matrix and distributing applications with Replicated. +Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to using CMX and distributing applications with Replicated. If you use GitHub Actions as your CI/CD platform, you can include these custom actions in your workflows rather than using Replicated CLI commands. Integrating the Replicated GitHub actions into your CI/CD pipeline helps you quickly build workflows with the required inputs and outputs, without needing to manually create the required CLI commands for each step. @@ -20,7 +20,7 @@ For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-wo ### Recommended Workflows -Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). For example development and release workflows that integrate Compatibility Matrix for testing, see [Recommended CI/CD Workflows](/vendor/ci-workflows). +Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). For example development and release workflows that integrate CMX for testing, see [Recommended CI/CD Workflows](/vendor/ci-workflows). ### Test Script Recommendations diff --git a/docs/vendor/testing-cluster-addons.md b/docs/vendor/testing-cluster-addons.md index 8604ce24a5..930aded4d0 100644 --- a/docs/vendor/testing-cluster-addons.md +++ b/docs/vendor/testing-cluster-addons.md @@ -1,10 +1,10 @@ -# Compatibility Matrix Cluster Add-ons (Alpha) +# CMX Cluster Add-ons (Alpha) -This topic describes the supported cluster add-ons for Replicated Compatibility Matrix. +This topic describes the supported cluster add-ons for Replicated Compatibility Matrix (CMX). ## Overview -Replicated Compatibility Matrix enables you to extend your cluster with add-ons, to make use of by your application, such as an AWS S3 object store. +CMX enables you to extend your cluster with add-ons, to make use of by your application, such as an AWS S3 object store. This allows you to more easily provision dependencies required by your application. ## CLI @@ -13,7 +13,7 @@ The Replicated CLI can be used to [create](/reference/replicated-cli-cluster-add ## Supported Add-ons -This section lists the supported cluster add-ons for clusters created with Compatibility Matrix. +This section lists the supported cluster add-ons for clusters created with CMX. ### object-store (Alpha) diff --git a/docs/vendor/testing-how-to.md b/docs/vendor/testing-how-to.md index 2ff1cd3818..8f581b994a 100644 --- a/docs/vendor/testing-how-to.md +++ b/docs/vendor/testing-how-to.md @@ -1,42 +1,42 @@ import Prerequisites from "../partials/cmx/_prerequisites.mdx" -# Use Compatibility Matrix Clusters +# Use CMX Clusters -This topic describes how to use Replicated Compatibility Matrix to create and manage ephemeral clusters to test your applications across different Kubernetes distributions and versions. +This topic describes how to use Replicated Compatibility Matrix (CMX) to create and manage ephemeral clusters to test your applications across different Kubernetes distributions and versions. -This topic includes information about creating and managing clusters with Compatibility Matrix using the Replicated Vendor Portal or the Replicated CLI. For information about creating and managing clusters with the Vendor API v3, see the [clusters](https://replicated-vendor-api.readme.io/reference/listclusterusage) section in the Vendor API v3 documentation. +This topic includes information about creating and managing clusters with CMX using the Replicated Vendor Portal or the Replicated CLI. For information about creating and managing clusters with the Vendor API v3, see the [clusters](https://replicated-vendor-api.readme.io/reference/listclusterusage) section in the Vendor API v3 documentation. -## About Compatibility Matrix Clusters +## About CMX Clusters -Compatibility Matrix supports both VM-based clusters (such as kind, k3s, RKE2, OpenShift, and Embedded Cluster) and cloud-managed clusters (such as EKS, GKE, and AKS). VM-based clusters run on Replicated bare metal servers, while cloud clusters are provisioned in Replicated-managed cloud accounts for faster delivery. +CMX supports both VM-based clusters (such as kind, k3s, RKE2, OpenShift, and Embedded Cluster) and cloud-managed clusters (such as EKS, GKE, and AKS). VM-based clusters run on Replicated bare metal servers, while cloud clusters are provisioned in Replicated-managed cloud accounts for faster delivery. -You can use Compatibility Matrix clusters for testing and troubleshooting Kubernetes-based deployments and Helm installations for your application. +You can use CMX clusters for testing and troubleshooting Kubernetes-based deployments and Helm installations for your application. -For information about creating VMs with Compatibility Matrix to test Replicated Embedded Cluster installers or when you need full OS control, see [Create VMs](/vendor/testing-vm-create). +For information about creating VMs with CMX to test Replicated Embedded Cluster installers or when you need full OS control, see [Create VMs](/vendor/testing-vm-create). ## Limitations -Compatibility Matrix has the following limitations: +CMX has the following limitations: - Clusters cannot be resized. Create another cluster if you want to make changes, such as add another node. - Clusters cannot be rebooted. Create another cluster if you need to reset/reboot the cluster. -- On cloud clusters, node groups are not available for every distribution. For distribution-specific details, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters). -- Multi-node support is not available for every distribution. For distribution-specific details, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters). -- ARM instance types are only supported on Cloud Clusters. For distribution-specific details, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters). -- GPU instance types are only supported on Cloud Clusters. For distribution-specific details, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters). +- On cloud clusters, node groups are not available for every distribution. For distribution-specific details, see [Supported CMX Cluster Types](/vendor/testing-supported-clusters). +- Multi-node support is not available for every distribution. For distribution-specific details, see [Supported CMX Cluster Types](/vendor/testing-supported-clusters). +- ARM instance types are only supported on Cloud Clusters. For distribution-specific details, see [Supported CMX Cluster Types](/vendor/testing-supported-clusters). +- GPU instance types are only supported on Cloud Clusters. For distribution-specific details, see [Supported CMX Cluster Types](/vendor/testing-supported-clusters). - There is no support for IPv6 as a single stack. Dual stack support is available on kind clusters. - The `cluster upgrade` feature is available only for kURL distributions. See [cluster upgrade](/reference/replicated-cli-cluster-upgrade). - Cloud clusters do not allow for the configuration of CNI, CSI, CRI, Ingress, or other plugins, add-ons, services, and interfaces. -- The node operating systems for clusters created with Compatibility Matrix cannot be configured nor replaced with different operating systems. -- The Kubernetes scheduler for clusters created with Compatibility Matrix cannot be replaced with a different scheduler. +- The node operating systems for clusters created with CMX cannot be configured nor replaced with different operating systems. +- The Kubernetes scheduler for clusters created with CMX cannot be replaced with a different scheduler. - Each team has a quota limit on the amount of resources that can be used simultaneously. This limit can be raised by messaging your account representative. -- Team actions with Compatibility Matrix (for example, creating and deleting clusters and requesting quota increases) are not logged and displayed in the [Vendor Team Audit Log](https://vendor.replicated.com/team/audit-log). +- Team actions with CMX (for example, creating and deleting clusters and requesting quota increases) are not logged and displayed in the [Vendor Team Audit Log](https://vendor.replicated.com/team/audit-log). -For additional distribution-specific limitations, see [Supported Compatibility Matrix Cluster Types](testing-supported-clusters). +For additional distribution-specific limitations, see [Supported CMX Cluster Types](testing-supported-clusters). ## Prerequisites -Before you can use Compatibility Matrix clusters, you must complete the following prerequisites: +Before you can use CMX clusters, you must complete the following prerequisites: @@ -44,7 +44,7 @@ Before you can use Compatibility Matrix clusters, you must complete the followin ## Create Clusters -You can create clusters with Compatibility Matrix using the Replicated CLI or the Vendor Portal. +You can create clusters with CMX using the Replicated CLI or the Vendor Portal. ### With the Replicated CLI @@ -253,7 +253,7 @@ For command usage, including additional options, see [cluster prepare](/referenc ## Access Clusters -Compatibility Matrix provides the kubeconfig for clusters so that you can access clusters with the kubectl command line tool. For more information, see [Command line tool (kubectl)](https://kubernetes.io/docs/reference/kubectl/) in the Kubernetes documentation. +CMX provides the kubeconfig for clusters so that you can access clusters with the kubectl command line tool. For more information, see [Command line tool (kubectl)](https://kubernetes.io/docs/reference/kubectl/) in the Kubernetes documentation. To access a cluster from the command line: @@ -283,7 +283,7 @@ To access a cluster from the command line: ## Upgrade Clusters (kURL Only) -For kURL clusters provisioned with Compatibility Matrix, you can use the the `cluster upgrade` command to upgrade the version of the kURL installer specification used to provision the cluster. A recommended use case for the `cluster upgrade` command is for testing your application's compatibility with Kubernetes API resource version migrations after upgrade. +For kURL clusters provisioned with CMX, you can use the the `cluster upgrade` command to upgrade the version of the kURL installer specification used to provision the cluster. A recommended use case for the `cluster upgrade` command is for testing your application's compatibility with Kubernetes API resource version migrations after upgrade. The following example upgrades a kURL cluster from its previous version to version `9d5a44c`: diff --git a/docs/vendor/testing-ingress.md b/docs/vendor/testing-ingress.md index a2b45cc8ed..f0a090b005 100644 --- a/docs/vendor/testing-ingress.md +++ b/docs/vendor/testing-ingress.md @@ -1,19 +1,19 @@ -# Compatibility Matrix Cluster Networking +# CMX Cluster Networking -This topic describes the networking options for accessing applications deployed on clusters created with Replicated Compatibility Matrix. It also describes how to use and manage Compatibility Matrix tunnels. +This topic describes the networking options for accessing applications deployed on clusters created with Replicated Compatibility Matrix (CMX). It also describes how to use and manage CMX tunnels. ## Networking Options -After deploying your application into Compatibility Matrix clusters, you will want to execute your tests using your own test runner. +After deploying your application into CMX clusters, you will want to execute your tests using your own test runner. In order to do this, you need to access your application. -Compatibility matrix offers several methods to access your application. +CMX offers several methods to access your application. Some standard Kubernetes networking options are available, but vary based on the distribution. For VM-based distributions, there is no default network route into the cluster, making inbound connections challenging to create. ### Port Forwarding Port forwarding is a low-cost and portable mechanism to access your application. -Port forwarding works on all clusters supported by Compatibility Matrix because the connection is initiated from the client, over the Kubernetes API server port. +Port forwarding works on all clusters supported by CMX because the connection is initiated from the client, over the Kubernetes API server port. If you have a single service or pod and are not worried about complex routing, this is a good mechanism. The basic steps are to connect the port-forward, execute your tests against localhost, and then shut down the port-forward. @@ -27,9 +27,9 @@ You can then query the service definition using `kubectl` and connect to and exe Ingress is a good way to recreate customer-representative environments, but the problem still remains on how to get inbound access to the IP address that the ingress controller allocates. Ingress is also not perfectly portable; each ingress controller might require different annotations in the ingress resource to work properly. Supported ingress controllers vary based on the distribution. -Compatibility matrix supports ingress controllers that are running as a `NodePort` service. +CMX supports ingress controllers that are running as a `NodePort` service. -### Compatibility Matrix Tunnels -All VM-based Compatibility Matrix clusters support tunneling traffic into a `NodePort` service. +### CMX Tunnels +All VM-based CMX clusters support tunneling traffic into a `NodePort` service. When this option is used, Replicated is responsible for creating the DNS record and TLS certs. Replicated will route traffic from `:443` and/or `:80` into the `NodePort` service you defined. For more information about using tunnels, see [Expose Ports Using Tunnels](testing-vm-networking). \ No newline at end of file diff --git a/docs/vendor/testing-network-policy.md b/docs/vendor/testing-network-policy.md index 4eee2f18c5..9fc76d2033 100644 --- a/docs/vendor/testing-network-policy.md +++ b/docs/vendor/testing-network-policy.md @@ -1,10 +1,10 @@ # Test in Air Gap Environments (Beta) -This topic describes how to change the network policy of a virtual machine (VM) or a VM-based cluster with Replicated Compatibility Matrix, and how to collect and analyze network events to understand your application's behavior in air-gapped environments. +This topic describes how to change the network policy of a virtual machine (VM) or a VM-based cluster with Replicated Compatibility Matrix (CMX), and how to collect and analyze network events to understand your application's behavior in air-gapped environments. ## Set Network Policy to `airgap` -VMs and [VM-based clusters](/vendor/testing-supported-clusters#vm-clusters) created with Compatibility Matrix can use one of the following network policies: +VMs and [VM-based clusters](/vendor/testing-supported-clusters#vm-clusters) created with CMX can use one of the following network policies: | Network Policy | Description | | :---- | :---- | @@ -110,7 +110,7 @@ To set the network policy of a VM: ## Collect and View Network Reports -Compatibility Matrix network reporting helps you understand your application's network activity. To provide flexibility in testing, you can enable network reporting to capture all network activity, whether the network policy is set to `open` or `airgap`. Even when the network policy is set to `airgap` and network egress is blocked, all connection attempts and DNS queries are still captured in the report. This helps you identify unexpected network calls before deploying to an air-gapped environment. +CMX network reporting helps you understand your application's network activity. To provide flexibility in testing, you can enable network reporting to capture all network activity, whether the network policy is set to `open` or `airgap`. Even when the network policy is set to `airgap` and network egress is blocked, all connection attempts and DNS queries are still captured in the report. This helps you identify unexpected network calls before deploying to an air-gapped environment. Network reporting is not enabled by default. For information about how to collect and view reports through the Vendor Portal or the Replicated CLI, see the sections below. diff --git a/docs/vendor/testing-pricing.mdx b/docs/vendor/testing-pricing.mdx index dc873f79d2..a2e2edc309 100644 --- a/docs/vendor/testing-pricing.mdx +++ b/docs/vendor/testing-pricing.mdx @@ -1,19 +1,19 @@ -# Compatibility Matrix Pricing +# CMX Pricing -This topic describes the pricing for Replicated Compatibility Matrix. +This topic describes the pricing for Replicated Compatibility Matrix (CMX). ## Usage-Based Pricing -There is a minimum cost of $0.50 plus one minute for each running cluster or VM created with Compatibility Matrix. Cost is rounded up to the nearest cent and subtracted from the available credits in the team account. +There is a minimum cost of $0.50 plus one minute for each running cluster or VM created with CMX. Cost is rounded up to the nearest cent and subtracted from the available credits in the team account. -The following provides more detail about the costs that are included in Compatibility Matrix usage-based pricing: +The following provides more detail about the costs that are included in CMX usage-based pricing: * A $0.50 per cluster or VM startup cost. * By-the-minute pricing based on instance size and count, starting at the time the cluster or VM status is `running` and ending when the cluster or VM is either expired (TTL) or removed. Minutes are rounded up. :::note - You are billed _only_ for the time that the cluster status is `running`. You are _not_ billed for the time that it takes Compatibility Matrix to create, verify, and tear down clusters and VMs. You can view the status of clusters and VMs using the [`replicated cluster ls`](/reference/replicated-cli-cluster-ls) and [`replicated vm ls`](/reference/replicated-cli-vm-ls) commands. + You are billed _only_ for the time that the cluster status is `running`. You are _not_ billed for the time that it takes CMX to create, verify, and tear down clusters and VMs. You can view the status of clusters and VMs using the [`replicated cluster ls`](/reference/replicated-cli-cluster-ls) and [`replicated vm ls`](/reference/replicated-cli-vm-ls) commands. For VMs, a `running` status indicates an SSH endpoint is available. For clusters, a `running` status indicates a working kubeconfig for the cluster is accessible. Additionally, clusters are verified prior to transitioning to a `running` status. Verification includes checking that the cluster is healthy and running with the correct number of nodes, as well as passing sonobuoy tests in `--quick` mode. ::: @@ -30,7 +30,7 @@ Team members assigned the Admin role receive a warning to their email address wh ## Quotas and Capacity -By default, Compatibility Matrix sets quotas for the capacity that can be used concurrently by each Vendor Portal team. These quotas are designed to ensure that Replicated maintains a minimum amount of capacity for provisioning VMs and clusters. +By default, CMX sets quotas for the capacity that can be used concurrently by each Vendor Portal team. These quotas are designed to ensure that Replicated maintains a minimum amount of capacity for provisioning VMs and clusters. By default, the quota for cloud-based cluster distributions (AKS, GKE, EKS) is three clusters running concurrently. diff --git a/docs/vendor/testing-shared-networks.md b/docs/vendor/testing-shared-networks.md index aa22b7f925..ff983b43ee 100644 --- a/docs/vendor/testing-shared-networks.md +++ b/docs/vendor/testing-shared-networks.md @@ -1,10 +1,10 @@ # Use Shared Networks -This topic explains how to create VMs and clusters with Replicated Compatibility Matrix on the same network. +This topic explains how to create VMs and clusters with Replicated Compatibility Matrix (CMX) on the same network. ## Connect a VM with a Cluster on the Same Network -You can make a Compatibility Matrix cluster available on the same network as a Compatibility Matrix VM. +You can make a CMX cluster available on the same network as a CMX VM. #### Supported Cluster Distributions diff --git a/docs/vendor/testing-supported-clusters.md b/docs/vendor/testing-supported-clusters.md index 5de0e0bb12..a587d2a70c 100644 --- a/docs/vendor/testing-supported-clusters.md +++ b/docs/vendor/testing-supported-clusters.md @@ -1,23 +1,23 @@ import Pool from "../partials/cmx/_openshift-pool.mdx" import InstanceTypes from "../partials/cmx/_instance-types.mdx" -# Compatibility Matrix Cluster Types +# CMX Cluster Types -This topic describes the supported Kubernetes distributions, Kubernetes versions, instance types, nodes, limitations, and common use cases for clusters created with Replicated Compatibility Matrix. +This topic describes the supported Kubernetes distributions, Kubernetes versions, instance types, nodes, limitations, and common use cases for clusters created with Replicated Compatibility Matrix (CMX). -Compatibility Matrix provisions cloud-based or virtual machine (VM) clusters. +CMX provisions cloud-based or virtual machine (VM) clusters. ## VM Clusters -This section lists the supported VM cluster distributions for clusters created with Compatibility Matrix. +This section lists the supported VM cluster distributions for clusters created with CMX. -VM-based clusters refers to clusters that run on Hetzner servers with the Compatibility Matrix cluster provisioner. This allows for greater flexibility than with Cloud Clusters like AWS, EKS, etc. For example, with VM-based distributions, Compatibility Matrix offers warm pools to make Openshift startup times very fast. +VM-based clusters refers to clusters that run on Hetzner servers with the CMX cluster provisioner. This allows for greater flexibility than with Cloud Clusters like AWS, EKS, etc. For example, with VM-based distributions, CMX offers warm pools to make Openshift startup times very fast. For information about provisioning VMs, which come without pre-installed clusters and allow for more access to the OS, see [Create VMs](testing-vm-create). ### kind -Compatibility Matrix supports creating [kind](https://kind.sigs.k8s.io/) clusters. +CMX supports creating [kind](https://kind.sigs.k8s.io/) clusters. @@ -60,7 +60,7 @@ Compatibility Matrix supports creating [kind](https://kind.sigs.k8s.io/) cluster ### k3s -Compatibility Matrix supports creating [k3s](https://k3s.io) clusters. +CMX supports creating [k3s](https://k3s.io) clusters.
@@ -107,7 +107,7 @@ Compatibility Matrix supports creating [k3s](https://k3s.io) clusters. ### RKE2 (Beta) -Compatibility Matrix supports creating [RKE2](https://docs.rke2.io/) clusters. +CMX supports creating [RKE2](https://docs.rke2.io/) clusters.
@@ -154,7 +154,7 @@ Compatibility Matrix supports creating [RKE2](https://docs.rke2.io/) clusters. ### OpenShift OKD -Compatibility Matrix supports creating [Red Hat OpenShift OKD](https://www.okd.io/) clusters, which is the community distribution of OpenShift, using CodeReady Containers (CRC). +CMX supports creating [Red Hat OpenShift OKD](https://www.okd.io/) clusters, which is the community distribution of OpenShift, using CodeReady Containers (CRC). OpenShift clusters are provisioned with two users: @@ -213,7 +213,7 @@ By default, kubeconfig context is set to the `kubeadmin` user. To switch to the ### Embedded Cluster -Compatibility Matrix supports creating clusters with Replicated Embedded Cluster. For more information, see [Embedded Cluster Overview](/vendor/embedded-overview). +CMX supports creating clusters with Replicated Embedded Cluster. For more information, see [Embedded Cluster Overview](/vendor/embedded-overview).
@@ -262,7 +262,7 @@ Compatibility Matrix supports creating clusters with Replicated Embedded Cluster ### kURL -Compatibility Matrix supports creating [kURL](https://kurl.sh) clusters. +CMX supports creating [kURL](https://kurl.sh) clusters.
@@ -309,7 +309,7 @@ This section lists the supported cloud clusters for compatibility testing. ### EKS -Compatibility Matrix supports creating [AWS EKS](https://aws.amazon.com/eks/?nc2=type_a) clusters. +CMX supports creating [AWS EKS](https://aws.amazon.com/eks/?nc2=type_a) clusters.
@@ -354,7 +354,7 @@ Compatibility Matrix supports creating [AWS EKS](https://aws.amazon.com/eks/?nc2 ### GKE -Compatibility Matrix supports creating [Google GKE](https://cloud.google.com/kubernetes-engine) clusters. +CMX supports creating [Google GKE](https://cloud.google.com/kubernetes-engine) clusters.
@@ -397,7 +397,7 @@ Compatibility Matrix supports creating [Google GKE](https://cloud.google.com/kub ### AKS -Compatibility Matrix supports creating [Azure AKS](https://azure.microsoft.com/en-us/products/kubernetes-service) clusters. +CMX supports creating [Azure AKS](https://azure.microsoft.com/en-us/products/kubernetes-service) clusters.
@@ -440,7 +440,7 @@ Compatibility Matrix supports creating [Azure AKS](https://azure.microsoft.com/e ### OKE (Beta) -Compatibility Matrix supports creating [Oracle Container Engine for Kubernetes (OKE)](https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengoverview.htm) clusters. +CMX supports creating [Oracle Container Engine for Kubernetes (OKE)](https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengoverview.htm) clusters.
@@ -483,10 +483,10 @@ Compatibility Matrix supports creating [Oracle Container Engine for Kubernetes ( ## Replicated Instance Types {#types} -When creating a VM-based cluster with Compatibility Matrix, you must specify a Replicated instance type. +When creating a VM-based cluster with CMX, you must specify a Replicated instance type. ## Kubernetes Version Support Policy -We do not maintain forks or patches of the supported distributions. When a Kubernetes version in Compatibility Matrix is out of support (EOL), Replicated will attempt to continue to support this version for six months for compatibility testing to support customers who are running out-of-date versions of Kubernetes. In the event that a critical security issue or bug is found and unresolved, we might discontinue support for EOL versions of Kubernetes prior to 6 months post EOL. +We do not maintain forks or patches of the supported distributions. When a Kubernetes version in CMX is out of support (EOL), Replicated will attempt to continue to support this version for six months for compatibility testing to support customers who are running out-of-date versions of Kubernetes. In the event that a critical security issue or bug is found and unresolved, we might discontinue support for EOL versions of Kubernetes prior to 6 months post EOL. diff --git a/docs/vendor/testing-vm-about.md b/docs/vendor/testing-vm-about.md index d27d459d51..c87e3fc709 100644 --- a/docs/vendor/testing-vm-about.md +++ b/docs/vendor/testing-vm-about.md @@ -1,17 +1,17 @@ import Prerequisites from "../partials/cmx/_prerequisites.mdx" import InstanceTypes from "../partials/cmx/_instance-types.mdx" -# About Compatibility Matrix VMs (Beta) +# About CMX VMs (Beta) -This topic describes Compatibility Matrix VMs and their capabilities for testing your applications. +This topic provides an introduction to Replicated Compatibility Matrix (CMX) VMs, including information about supported types, limitations, and prerequisites to use CMX VMs. -## About Compatibility Matrix VMs +## About CMX VMs -Compatibility Matrix VMs provide isolated Linux environments for testing your applications. Unlike clusters, VMs give you full control over the operating system (OS) and allow you to test installation methods that require direct OS access. +CMX VMs provide isolated Linux environments for testing your applications. Unlike clusters, VMs give you full control over the operating system (OS) and allow you to test installation methods that require direct OS access. -You can use Compatibility Matrix VMs for testing and troubleshooting VM-based installations for your application with [Replicated Embedded Cluster](/intro-replicated#embedded-cluster). +You can use CMX VMs for testing and troubleshooting VM-based installations for your application with [Replicated Embedded Cluster](/intro-replicated#embedded-cluster). -For information about creating clusters with Compatibility Matrix to test Kubernetes-based deployments and Helm installations, see [Create and Manage Clusters](/vendor/testing-how-to). +For information about creating clusters with CMX to test Kubernetes-based deployments and Helm installations, see [Create and Manage Clusters](/vendor/testing-how-to). ## Supported VM Types @@ -30,16 +30,16 @@ The following describes the Replicated instance types for VMs: ## Limitations -Creating VMs with Compatibility Matrix has the following limitations: +Creating VMs with CMX has the following limitations: -- Creating VMs with Compatibility Matrix is a Beta feature. -- Installing Embedded Cluster on a VM created with Compatibility Matrix is supported for Embedded Cluster versions 1.21.0 or later. -- [GitHub Actions](/vendor/testing-ci-cd#replicated-github-actions) are not supported for Compatibility Matrix VMs. -- The [cluster prepare](/reference/replicated-cli-cluster-prepare) command is not supported for Compatibility Matrix VMs. +- Creating VMs with CMX is a Beta feature. +- Installing Embedded Cluster on a VM created with CMX is supported for Embedded Cluster versions 1.21.0 or later. +- [GitHub Actions](/vendor/testing-ci-cd#replicated-github-actions) are not supported for CMX VMs. +- The [cluster prepare](/reference/replicated-cli-cluster-prepare) command is not supported for CMX VMs. ## Prerequisites -Before you can use Compatibility Matrix VMs, you must complete the following prerequisites: +Before you can use CMX VMs, you must complete the following prerequisites: diff --git a/docs/vendor/testing-vm-create.md b/docs/vendor/testing-vm-create.md index 5baaa03c8c..2bd552098e 100644 --- a/docs/vendor/testing-vm-create.md +++ b/docs/vendor/testing-vm-create.md @@ -1,9 +1,10 @@ -# Use Compatibility Matrix VMs (Beta) +# Use CMX VMs (Beta) -This topic describes how to use Replicated Compatibility Matrix to create and manage ephemeral VMs. +This topic describes how to use Replicated Compatibility Matrix (CMX) to create and manage ephemeral VMs. ## Set Up SSH Access + To access VMs that you create with Compatibility Matrix, you need to set up SSH access. You can do this using your GitHub account, a personal public/private key, or a service account or bot with shared access. ### Use Your GitHub Account @@ -12,7 +13,9 @@ To access VMs that you create with Compatibility Matrix, you need to set up SSH Your GitHub usernames and SSH keys are synced to a VM when it is first created. If you update your GitHub username or keys after creating a VM, you can manually sync by updating your [Account Settings](https://vendor.replicated.com/account-settings) in the Vendor Portal and clicking **Save**. ::: -To set up and verify SSH access for Compatibility Matrix VMs using your personal GitHub account: +### Use Your GitHub Account + +To set up and verify SSH access for CMX VMs using your personal GitHub account: 1. Log in to your GitHub account and add an SSH key if you do not have one already. For information about how to generate and add a new SSH key, see [Generate a new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generati[…]w-ssh-key) and [Adding a new SSH key to your GitHub account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) in the GitHub documentation. @@ -114,7 +117,7 @@ replicated vm create --distribution ubuntu --version 24.04 --ssh-public-key ~/.s ### With the Replicated CLI -To create VMs with Compatibility Matrix: +To create VMs with CMX: 1. (Optional) View the available VM distributions, including the supported VM distribution versions and instance types: @@ -219,13 +222,13 @@ To create a VM from the Vendor Portal: You can SSH into a VM using one of the following methods: -* [**Compatibility Matrix Forwarder**](#compatibility-matrix-forwarder): To use the Compatibility Matrix Forwarder, you only need to know the VM ID to connect to the machine with SSH. This is more approachable for users less familiar with SSH clients. +* [**CMX Forwarder**](#compatibility-matrix-forwarder): To use the CMX Forwarder, you only need to know the VM ID to connect to the machine with SSH. This is more approachable for users less familiar with SSH clients. -* [**Direct SSH**](#direct-ssh): When you connect to a VM using direct SSH, you can use your SSH tool of choice and pass any client supported flags, without any added connection lag of being routed through the Compatibility Matrix Forwarder. Example use cases for direct SSH include transferring large assets such as air gap bundles to the VM using SCP, or passing specific SHH flags during testing workflows. +* [**Direct SSH**](#direct-ssh): When you connect to a VM using direct SSH, you can use your SSH tool of choice and pass any client supported flags, without any added connection lag of being routed through the CMX Forwarder. Example use cases for direct SSH include transferring large assets such as air gap bundles to the VM using SCP, or passing specific SHH flags during testing workflows. For information about how to copy files to a VM after connecting, see [Copy Files to a VM](testing-vm-transfer-files). -### Compatibility Matrix Forwarder +### CMX Forwarder To connect to a VM using the Forwarder: diff --git a/docs/vendor/testing-vm-networking.md b/docs/vendor/testing-vm-networking.md index 28c0ff4b69..e15ed26bb9 100644 --- a/docs/vendor/testing-vm-networking.md +++ b/docs/vendor/testing-vm-networking.md @@ -1,6 +1,6 @@ -# Compatibility Matrix VM Networking +# CMX VM Networking -This topic explains how to expose ports on VMs and VM-based clusters created with Compatibility Matrix. +This topic explains how to expose ports on VMs and VM-based clusters created with Replicated Compatibility Matrix (CMX). ## Expose Ports on VMs @@ -52,7 +52,7 @@ You can expose a node port that does not yet exist in the cluster. This is useful if you have a deterministic node port, but need the DNS name as a value in your Helm chart. ::: -The following diagram shows how the traffic is routed into the service using Compatibility Matrix tunnels: +The following diagram shows how the traffic is routed into the service using CMX tunnels: Compatibility Matrix ingress diff --git a/docs/vendor/testing-vm-transfer-files.md b/docs/vendor/testing-vm-transfer-files.md index 2a16dd9f5d..bb6fb4adfb 100644 --- a/docs/vendor/testing-vm-transfer-files.md +++ b/docs/vendor/testing-vm-transfer-files.md @@ -1,8 +1,8 @@ # Copy Files to a VM -This topic describes how to transfer files to a VM created with Replicated Compatibility Matrix. +This topic describes how to transfer files to a VM created with Replicated Compatibility Matrix (CMX). -You can copy files to a VM either using direct SSH and an SCP endpoint, or by using SCP after connecting to the VM with the Compatibility Matrix Forwarder. Transferring files using direct SSH allows you to use your SSH tool of choice, and pass any client-supported flags. +You can copy files to a VM either using direct SSH and an SCP endpoint, or by using SCP after connecting to the VM with the CMX Forwarder. Transferring files using direct SSH allows you to use your SSH tool of choice, and pass any client-supported flags. ## Using the SCP Endpoint @@ -53,18 +53,18 @@ To copy files to a VM using the scp endpoint: ## After Connecting to the VM with the Forwarder :::note -Transferring files using Compatibility Matrix Forwarder is slower than using direct SSH due to added latency. If you want to transfer large files such as air gap bundles onto the VM, use direct SSH in combination with SCP. See [Using the SCP Endpoint](#using-the-scp-endpoint) above. +Transferring files using CMX Forwarder is slower than using direct SSH due to added latency. If you want to transfer large files such as air gap bundles onto the VM, use direct SSH in combination with SCP. See [Using the SCP Endpoint](#using-the-scp-endpoint) above. ::: #### Limitations -Transferring files using the Compatibility Matrix Forwarder has the following limitations: +Transferring files using the CMX Forwarder has the following limitations: - `scp` with flag `-O` (legacy scp protocol) is not supported. - Relative paths is not supported. For example: - Unsupported: `scp somefile VMID@replicatedvm.com:~` - Supported: `scp somefile VMID@replicatedvm:/home/folder/somefile` - File permissions are not inherited. -To copy files to the VM using SCP after connecting with the Compatibility Matrix Forwarder: +To copy files to the VM using SCP after connecting with the CMX Forwarder: 1. SSH into the VM using the Forwarder: diff --git a/docs/vendor/tutorial-embedded-cluster-automation.mdx b/docs/vendor/tutorial-embedded-cluster-automation.mdx index 94e7c30502..0dbbcc90a8 100644 --- a/docs/vendor/tutorial-embedded-cluster-automation.mdx +++ b/docs/vendor/tutorial-embedded-cluster-automation.mdx @@ -25,17 +25,17 @@ Before you begin, do the following to set up your environment: * Ensure that you have access to a VM that meets the requirements for Embedded Cluster: - * **Option 1: Use Compatibility Matrix.** To use Replicated Compatibility Matrix to create a VM, do the following before proceeding: + * **Option 1: Use Compatibility Matrix.** To use Replicated Compatibility Matrix (CMX) to create a VM, do the following before proceeding: - * Request Compatibility Matrix credits. You can request credits by creating a Vendor Portal account and then going to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix) in the Vendor Portal. For more information about creating an account, see [Create a Vendor Account](vendor-portal-creating-account). For more information about Compatibility Matrix credits, see [Billing and Credits](/vendor/testing-about#billing-and-credits). + * Request CMX credits. You can request credits by creating a Vendor Portal account and then going to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix) in the Vendor Portal. For more information about creating an account, see [Create a Vendor Account](vendor-portal-creating-account). For more information about CMX credits, see [Billing and Credits](/vendor/testing-about#billing-and-credits). :::note - If you are new to the Replicated platform, you might be eligible for $100 in free Compatibility Matrix credits. To request your free credits, reach out to our sales team at https://www.replicated.com/contact and note in the comments that you are completing a Replicated tutorial. + If you are new to the Replicated platform, you might be eligible for $100 in free CMX credits. To request your free credits, reach out to our sales team at https://www.replicated.com/contact and note in the comments that you are completing a Replicated tutorial. ::: - * Ensure that you have an SSH key in your GitHub account. Then, add your GitHub username to your Vendor Portal [**Account Settings**](https://vendor.replicated.com/account-settings). This will provide SSH access to VMs that you create with Compatibility Matrix. For more information, see [Set Up SSH Access](/vendor/testing-vm-create#set-up-ssh-access) in _Create VMs_. + * Ensure that you have an SSH key in your GitHub account. Then, add your GitHub username to your Vendor Portal [**Account Settings**](https://vendor.replicated.com/account-settings). This will provide SSH access to VMs that you create with CMX. For more information, see [Set Up SSH Access](/vendor/testing-vm-create#set-up-ssh-access) in _Create VMs_. - After you complete the prerequisites above, continue to the [Tutorial](#tutorial). You will create the VM with Compatibility Matrix as part of the tutorial. + After you complete the prerequisites above, continue to the [Tutorial](#tutorial). You will create the VM with CMX as part of the tutorial. * **Option 2: Bring your own VM.** Your VM must meet these requirements: @@ -169,7 +169,7 @@ Before you begin, do the following to set up your environment: 1. Click **Save Changes**. -### Create a Compatibility Matrix VM +### Create a CMX VM :::note If you are using your own VM, skip these steps and continue to [Create the ConfigValues](#create-the-configvalues) below. @@ -229,7 +229,7 @@ If you are using your own VM, skip these steps and continue to [Create the Confi slackernews_domain: value: YOUR_DOMAIN ``` - Where `YOUR_DOMAIN` is the domain to use for SlackerNews. For Compatibility Matrix VMs, this is the hostname for the DNS record with port 443 that you copied in a previous step. + Where `YOUR_DOMAIN` is the domain to use for SlackerNews. For CMX VMs, this is the hostname for the DNS record with port 443 that you copied in a previous step. **Example:** ```yaml @@ -248,7 +248,7 @@ If you are using your own VM, skip these steps and continue to [Create the Confi 1. SSH onto the VM. 1. Transfer the `slackernews-configvalues.yaml` file from your local machine to the VM. -* **If you are using a Compatibility Matrix VM:** +* **If you are using a CMX VM:** 1. In the Vendor Portal, go to [**Compatibility Matrix**](https://vendor.replicated.com/compatibility-matrix) and find the VM under the **Virtual Machines** provided. @@ -259,7 +259,7 @@ If you are using your own VM, skip these steps and continue to [Create the Confi 1. If you are prompted to add the fingerprint for replicatedvm.com, type `yes` and press Enter. - 1. When prompted, provide the passphrase for the SSH key in your linked GitHub account. Compatibility Matrix uses GitHub SSH to provide access to the VM. + 1. When prompted, provide the passphrase for the SSH key in your linked GitHub account. CMX uses GitHub SSH to provide access to the VM. 1. Open a new command prompt window. @@ -338,7 +338,7 @@ If you are using your own VM, skip these steps and continue to [Create the Confi 1. (Optional) Log in to the Admin Console using the password that you set with the `--admin-console-password` flag during installation: - * **Compatibility Matrix VMs:** The Admin Console domain is the hostname for the DNS record with port 30000 that you added to the VM. You can find this hostname by going to **Compatibility Matrix > Edit VM** in the Vendor Portal. + * **CMX VMs:** The Admin Console domain is the hostname for the DNS record with port 30000 that you added to the VM. You can find this hostname by going to **Compatibility Matrix > Edit VM** in the Vendor Portal. * **If you brought your own VM:** The Admin Console URL is provided in the output of the install command. :::note @@ -347,7 +347,7 @@ If you are using your own VM, skip these steps and continue to [Create the Confi 1. Clean up the installation: - * If you created the VM with Compatibility Matrix, delete the VM: + * If you created the VM with CMX, delete the VM: ```bash replicated vm rm VM_ID diff --git a/docs/vendor/tutorial-helm-cli.mdx b/docs/vendor/tutorial-helm-cli.mdx index 6ee59ca95a..dce730ec09 100644 --- a/docs/vendor/tutorial-helm-cli.mdx +++ b/docs/vendor/tutorial-helm-cli.mdx @@ -26,13 +26,13 @@ Before you begin, do the following to set up your environment: * Ensure that you have access to a Kubernetes cluster where you can test the installation using the Helm CLI: - * **Option 1: Use Compatibility Matrix.** To use Replicated Compatibility Matrix to create a cluster for this tutorial, first request Compatibility Matrix credits. You can request credits by creating a Vendor Portal account and then going to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix) in the Vendor Portal. For more information about creating an account, see [Create a Vendor Account](vendor-portal-creating-account). For more information about Compatibility Matrix credits, see [Billing and Credits](/vendor/testing-about#billing-and-credits). + * **Option 1: Use Compatibility Matrix.** To use Replicated Compatibility Matrix (CMX) to create a cluster for this tutorial, first request CMX credits. You can request credits by creating a Vendor Portal account and then going to [**Compatibility Matrix > Request more credits**](https://vendor.replicated.com/compatibility-matrix) in the Vendor Portal. For more information about creating an account, see [Create a Vendor Account](vendor-portal-creating-account). For more information about CMX credits, see [Billing and Credits](/vendor/testing-about#billing-and-credits). :::note - If you are new to the Replicated platform, you might be eligible for $100 in free Compatibility Matrix credits. To request your free credits, reach out to our sales team at https://www.replicated.com/contact and note in the comments that you are completing a Replicated tutorial. + If you are new to the Replicated platform, you might be eligible for $100 in free CMX credits. To request your free credits, reach out to our sales team at https://www.replicated.com/contact and note in the comments that you are completing a Replicated tutorial. ::: - After you complete the prerequisites described above, continue to the [Tutorial](#tutorial). You will create the cluster with Compatibility Matrix as part of the tutorial. + After you complete the prerequisites described above, continue to the [Tutorial](#tutorial). You will create the cluster with CMX as part of the tutorial. * **Option 2: Bring your own Cluster.** You can use any cloud provider or tool that you prefer to create a cluster, such as Google Kubernetes Engine (GKE) or minikube. @@ -215,7 +215,7 @@ Log in to the Enterprise Portal for the customer to get the Helm CLI installatio 1. For **Instance Name**, enter a nickname for the instance. -1. For **Kubernetes Distribution**, select the distribution of the cluster where you will install SlackerNews. If you are going to use Compatibility Matrix to create the cluster, select **Vanilla Kubernetes**. +1. For **Kubernetes Distribution**, select the distribution of the cluster where you will install SlackerNews. If you are going to use CMX to create the cluster, select **Vanilla Kubernetes**. 1. For **Cluster Network Availability**, select **Outbound requests allowed**. @@ -227,7 +227,7 @@ Log in to the Enterprise Portal for the customer to get the Helm CLI installatio Install SlackerNews in a cluster: -1. If you brought your own cluster, set kubectl context to the cluster where you want to install. If you are using Compatibility Matrix, do the following: +1. If you brought your own cluster, set kubectl context to the cluster where you want to install. If you are using CMX, do the following: 1. Create a kind cluster with version 1.34.0 of Kubernetes: