CMX Air Gap Testing more visible in sidebar

docs/reference/replicated-cli-network-report.mdx

@@ -0,0 +1,49 @@
+# replicated network report
+
+Get network report
+
+### Synopsis
+
+Get a report showing network events for a specified network. You can view all network events, or use the --summary flag to see an aggregated analysis of captured network events.
+
+Network reporting is a beta feature. For more information, see [Test in Air Gap Environments (Beta)](/vendor/testing-network-policy).
+
+```
+replicated network report [network-id] [flags]
+```
+
+### Examples
+
+```
+# Get report for a network by ID (using positional argument)
+replicated network report abc123
+
+# Get report for a network by ID (using flag)
+replicated network report --id abc123
+
+# Watch for new network events (JSON Lines format)
+replicated network report abc123 --watch
+```
+
+### Options
+
+```
+  -h, --help       help for report
+      --id string  Network ID to get report for
+      --summary    Get the report summary
+  -w, --watch      Watch for new network events
+```
+
+### Options inherited from parent commands
+
+```
+      --app string     The app slug or app id to use in all calls
+      --debug          Enable debug output
+      --token string   The API token to use to access your app in the Vendor API
+```
+
+### SEE ALSO
+
+* [replicated network](replicated-cli-network)	 - Manage test networks for VMs and Clusters
+
+

docs/reference/replicated-cli-network.mdx

@@ -16,6 +16,9 @@ replicated network ls
 # Update a network with an airgap policy
 replicated network update <network-id> --policy airgap
 
+# View network report
+replicated network report <network-id> --summary
+
 ```
 
 ### Options
@@ -36,5 +39,6 @@ replicated network update <network-id> --policy airgap
 
 * [replicated](replicated)	 - Manage your Commercial Software Distribution Lifecycle using Replicated
 * [replicated network ls](replicated-cli-network-ls)	 - List test networks
+* [replicated network report](replicated-cli-network-report)	 - View network activity reports
 * [replicated network update](replicated-cli-network-update)	 - Update network settings
 

docs/vendor/compatibility-matrix-usage.md

@@ -1,4 +1,4 @@
-# View Compatibility Matrix Usage History
+# Compatibility Matrix Usage History
 This topic describes using the Replicated Vendor Portal to understand
 Compatibility Matrix usage across your team.
 

docs/vendor/environment-setup.mdx

@@ -283,6 +283,6 @@ You need access to a VM to test installations and updates with the [Replicated E
 
 To test installations with Helm, you need kubectl access to a cluster.
 
-* **Option 1: Use Compatibility Matrix.** You can use Replicated Compatibility Matrix to create clusters. For more information, see [Create Clusters](/vendor/testing-how-to).
+* **Option 1: Use Compatibility Matrix.** You can use Replicated Compatibility Matrix to create clusters. For more information, see [Create and Manage Clusters](/vendor/testing-how-to).
 
 * **Option 2: Use another cloud provider or tool.** You can use any cloud provider or tool that you prefer to create a cluster, such as Google Kubernetes Engine (GKE) or minikube.

docs/vendor/support-inspecting-support-bundles.md

@@ -26,7 +26,7 @@ To inspect a support bundle:
 
 1. (Optional) Click **Download bundle** to download the bundle. This can be helpful if you want to access the bundle from another system or if other team members want to access the bundle and use other tools to examine the files.
 
-1. (Optional) Navigate back to the [**Troubleshoot**](https://vendor.replicated.com/troubleshoot) page and click **Create cluster** to provision a cluster with Replicated Compatibility Matrix. This can be helpful for creating customer-representative environments for troubleshooting. For more information about creating clusters with Compatibility Matrix, see [Use Compatibility Matrix](testing-how-to).
+1. (Optional) Navigate back to the [**Troubleshoot**](https://vendor.replicated.com/troubleshoot) page and click **Create cluster** to provision a cluster with Replicated Compatibility Matrix. This can be helpful for creating customer-representative environments for troubleshooting. For more information about creating clusters with Compatibility Matrix, see [Create and Manage Clusters](testing-how-to).
 
     <img alt="Cluster configuration dialog" src="/images/cmx-cluster-configuration.png" width="400px"/>
 

docs/vendor/testing-about.md

@@ -11,7 +11,7 @@ Example use cases for Compatibility Matrix include:
 * 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 Clusters](testing-how-to) and [Create VMs](testing-vm-create).
+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).
 
 ## Supported Clusters and VMs
 

docs/vendor/testing-ci-cd.md

@@ -1,6 +1,6 @@
 import TestRecs from "../partials/ci-cd/_test-recs.mdx"
 
-# Use Compatibility Matrix with CI/CD
+# Test in Compatibility Matrix with CI/CD
 
 This topic describes how to integrate Replicated Compatibility Matrix into your CI/CD workflows.
 

docs/vendor/testing-how-to.md

@@ -1,6 +1,6 @@
 import Prerequisites from "../partials/cmx/_prerequisites.mdx"
 
-# Create Clusters
+# Use Compatibility Matrix 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.
 
@@ -25,7 +25,6 @@ Compatibility Matrix has the following limitations:
 - 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).
 - There is no support for IPv6 as a single stack. Dual stack support is available on kind clusters.
-- There is no support for air gap testing. 
 - 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.
@@ -171,6 +170,28 @@ To create a cluster using the Vendor Portal:
 
    [View a larger version of this image](/images/cmx-assigned-cluster.png)
 
+## Create Air Gap Clusters (Beta)
+
+For any VM-based cluster distributions, you can create a cluster that uses an air-gapped network by setting the network policy to `airgap`.
+
+For more information, see [Use Air Gap Networks (Beta)](testing-network-policy).
+
+To set the network policy of a VM-based cluster to `airgap`:
+
+1. Create a cluster:
+
+   ```bash
+   replicated cluster create --distribution VM_BASED_DISTRIBUTION
+   ```
+   Where `VM_BASED_DISTRIBUTION` is the target VM-based cluster distribution. For a list of supported distributions, see [VM Clusters](/vendor/testing-supported-clusters#vm-clusters).
+
+1. Change the network policy to `airgap`:
+
+   ```bash
+   replicated network update NETWORK_ID --policy airgap
+   ```
+   Where `NETWORK_ID` is the ID of the network from the output of the `cluster ls` command.
+
 ## Prepare Clusters
 
 For applications distributed with the Replicated Vendor Portal, the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) command reduces the number of steps required to provision a cluster and then deploy a release to the cluster for testing. This is useful in continuous integration (CI) workflows that run multiple times a day. For an example workflow that uses the `cluster prepare` command, see [Recommended CI/CD Workflows](/vendor/ci-workflows).

docs/vendor/testing-ingress.md

@@ -1,4 +1,4 @@
-# Cluster Networking
+# Compatibility Matrix 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.
 
@@ -32,83 +32,4 @@ Compatibility matrix supports ingress controllers that are running as a `NodePor
 ### Compatibility Matrix Tunnels
 All VM-based Compatibility Matrix 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 [Managing Compatibility Matrix Tunnels](#manage-nodes) below.
-
-The following diagram shows how the traffic is routed into the service using Compatibility Matrix tunnels:
-
-<img src="/images/compatibility-matrix-ingress.png" alt="Compatibility Matrix ingress"></img>
-
-[View a larger version of this image](/images/compatibility-matrix-ingress.png)
-
-## Managing Compatibility Matrix Tunnels {#manage-nodes}
-
-Tunnels are viewed, created, and removed using the Compatibility Matrix UI within Vendor Portal, the Replicated CLI, GitHub Actions, or directly with the Vendor API v3. There is no limit to the number of tunnels you can create for a cluster and multiple tunnels can connect to a single service, if desired.
-
-### Limitations
-
-Compatibility Matrix tunnels have the following limitations:
-* One tunnel can only connect to one service. If you need fanout routing into different services, consider installing the nginx ingress controller as a `NodePort` service and exposing it.
-* Tunnels are not supported for cloud distributions (EKS, GKE, AKS).
-
-### Supported Protocols
-
-A tunnel can support one or more protocols.
-The supported protocols are HTTP, HTTPS, WS and WSS.
-GRPC and other protocols are not routed into the cluster.
-
-### Exposing Ports
-Once you have a node port available on the cluster, you can use the Replicated CLI to expose the node port to the public internet. 
-This can be used multiple times on a single cluster.
-
-Optionally, you can specify the `--wildcard` flag to expose this port with wildcard DNS and TLS certificate.
-This feature adds extra time to provision the port, so it should only be used if necessary.
-
-```bash
-replicated cluster port expose \
-    [cluster id] \
-    --port [node port] \
-    --protocol [protocol] \
-    --wildcard
-```
-
-For example, if you have the nginx ingress controller installed and the node port is 32456:
-
-```bash
-% replicated cluster ls
-ID          NAME                           DISTRIBUTION    VERSION       STATUS         
-1e616c55    tender_ishizaka                k3s             1.29.2        running        
-
-% replicated cluster port expose \
-    1e616c55 \
-    --port 32456 \
-    --protocol http \
-    --protocol https \
-    --wildcard
-```
-
-:::note
-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.
-:::
-
-### Viewing Ports
-To view all exposed ports, use the Replicated CLI `port ls` subcommand with the cluster ID:
-
-```bash
-% replicated cluster port ls 1e616c55
-ID              CLUSTER PORT    PROTOCOL        EXPOSED PORT                                            WILDCARD        STATUS
-d079b2fc        32456           http            http://happy-germain.ingress.replicatedcluster.com      true            ready
-
-d079b2fc        32456           https           https://happy-germain.ingress.replicatedcluster.com     true            ready
-```
-
-### Removing Ports
-Exposed ports are automatically deleted when a cluster terminates.
-If you want to remove a port (and the associated DNS records and TLS certs) prior to cluster termination, run the `port rm` subcommand with the cluster ID:
-
-```bash
-% replicated cluster port rm 1e616c55 --id d079b2fc
-```
-
-You can remove just one protocol, or all.
-Removing all protocols also removes the DNS record and TLS cert.
+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).