-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[OSDOCS-16094]: Adding warning about shared namespaces to HCP on Virt docs #109537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,7 +7,13 @@ | |
| [id="hcp-virt-create-hc-cli_{context}"] | ||
| = Creating a hosted cluster with the KubeVirt platform by using the CLI | ||
|
|
||
| To create a hosted cluster, you can use the hosted control plane command-line interface (CLI), `hcp`. | ||
| [role="_abstract"] | ||
| To create a hosted cluster on {VirtProductName}, you can use the hosted control plane command-line interface (CLI), `hcp`. | ||
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| Avoid storing all hosted cluster information in a shared namespace. If you create a hosted cluster in a shared namespace and then back up and restore the hosted cluster, you might unintentionally change other hosted clusters. Either store hosted cluster information in a separate namespace or set up your hosted cluster to back up and restore resources based on labels. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Will the typical user know what this means/how to do this?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point. I can add an xref in an Additional resources section that links to the docs about using labels. |
||
| ==== | ||
|
|
||
| .Procedure | ||
|
|
||
|
|
@@ -16,30 +22,28 @@ To create a hosted cluster, you can use the hosted control plane command-line in | |
| [source,terminal] | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The remainder of the changes in this file replace the number callouts with a list to prepare this document for migration to AEM. |
||
| ---- | ||
| $ hcp create cluster kubevirt \ | ||
| --name <hosted_cluster_name> \// <1> | ||
| --node-pool-replicas <node_pool_replica_count> \// <2> | ||
| --pull-secret <path_to_pull_secret> \// <3> | ||
| --memory <value_for_memory> \// <4> | ||
| --cores <value_for_cpu> \// <5> | ||
| --etcd-storage-class=<etcd_storage_class> \// <6> | ||
| --arch <architecture_of_the_nodepool> \// <7> | ||
| --release-image <ocp_release_image_for_the_cluster> <8> | ||
| --name <hosted_cluster_name> \ | ||
| --node-pool-replicas <node_pool_replica_count> \ | ||
| --pull-secret <path_to_pull_secret> \ | ||
| --memory <value_for_memory> \ | ||
| --cores <value_for_cpu> \ | ||
| --etcd-storage-class=<etcd_storage_class> \ | ||
| --arch <architecture_of_the_nodepool> \ | ||
| --release-image <ocp_release_image_for_the_cluster> | ||
| ---- | ||
| <1> Specify the name of your hosted cluster, for example, `my-hosted-cluster`. | ||
| <2> Specify the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created. | ||
| <3> Specify the path to your pull secret, for example, `/user/name/pullsecret`. | ||
| <4> Specify a value for memory, for example, `6Gi`. | ||
| <5> Specify a value for CPU, for example, `2`. | ||
| <6> Specify the etcd storage class name, for example, `lvm-storageclass`. | ||
| <7> Specify the architecture of the node pool, for example, `s390x`. The default is `amd64`. | ||
| <8> Specify the ocp release image for the cluster, for example, `quay.io/openshift-release-dev/ocp-release:4.20.14-multi`. | ||
| + | ||
| [NOTE] | ||
| ==== | ||
| You can use the `--release-image` flag to set up the hosted cluster with a specific {product-title} release. | ||
| ==== | ||
| -- | ||
| * `--name` defines the name of your hosted cluster, for example, `my-hosted-cluster`. | ||
| * `--node-pool-replicas` defines the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created. | ||
| * `--pull-secret` defines the path to your pull secret, for example, `/user/name/pullsecret`. | ||
| * `--memory` defines a value for memory, for example, `6Gi`. | ||
| * `--cores` defines a value for CPU, for example, `2`. | ||
| * `--etcd-storage-class` defines the etcd storage class name, for example, `lvm-storageclass`. | ||
| * `--arch` defines the architecture of the node pool, for example, `s390x`. The default is `amd64`. | ||
| * `--release-image` defines the {product-title} release image for the cluster, for example, `quay.io/openshift-release-dev/ocp-release:4.20.14-multi`. You can use the `--release-image` flag to set up the hosted cluster with a specific {product-title} release. | ||
| -- | ||
| + | ||
| A default node pool is created for the cluster with two virtual machine worker replicas according to the `--node-pool-replicas` flag. | ||
| A default node pool is created for the cluster with a specific number of virtual machine worker replicas according to the `--node-pool-replicas` flag. | ||
|
|
||
| . After a few moments, verify that the hosted control plane pods are running by entering the following command: | ||
| + | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,7 @@ | |
| [id="hcp-virt-create-hc-ext-infra_{context}"] | ||
| = Creating a hosted cluster with the KubeVirt platform by using external infrastructure | ||
|
|
||
| [role="_abstract"] | ||
| By default, the HyperShift Operator hosts both the control plane pods of the hosted cluster and the KubeVirt worker VMs within the same cluster. With the external infrastructure feature, you can place the worker node VMs on a separate cluster from the control plane pods. | ||
|
|
||
| - The _management cluster_ is the {product-title} cluster that runs the HyperShift Operator and hosts the control plane pods for a hosted cluster. | ||
|
|
@@ -14,6 +15,11 @@ By default, the HyperShift Operator hosts both the control plane pods of the hos | |
|
|
||
| - By default, the management cluster also acts as the infrastructure cluster that hosts VMs. However, for external infrastructure, the management and infrastructure clusters are different. | ||
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| Avoid storing all hosted cluster information in a shared namespace. If you create a hosted cluster in a shared namespace and then back up and restore the hosted cluster, you might unintentionally change other hosted clusters. Either store hosted cluster information in a separate namespace or set up your hosted cluster to back up and restore resources based on labels. | ||
| ==== | ||
|
|
||
| .Prerequisites | ||
|
|
||
| * You must have a namespace on the external infrastructure cluster for the KubeVirt nodes to be hosted in. | ||
|
|
@@ -22,28 +28,28 @@ By default, the HyperShift Operator hosts both the control plane pods of the hos | |
|
|
||
| .Procedure | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The remainder of the changes in this file replace the number callouts with a list to prepare this document for migration to AEM. |
||
|
|
||
| You can create a hosted cluster by using the `hcp` command-line interface. | ||
|
|
||
| * To place the KubeVirt worker VMs on the infrastructure cluster, use the `--infra-kubeconfig-file` and `--infra-namespace` arguments, as shown in the following example: | ||
| * In the `hcp` command-line interface, place the KubeVirt worker VMs on the infrastructure cluster, use the `--infra-kubeconfig-file` and `--infra-namespace` arguments, as shown in the following example: | ||
| + | ||
| [source,terminal] | ||
| ---- | ||
| $ hcp create cluster kubevirt \ | ||
| --name <hosted-cluster-name> \// <1> | ||
| --node-pool-replicas <worker-count> \// <2> | ||
| --pull-secret <path-to-pull-secret> \// <3> | ||
| --memory <value-for-memory> \// <4> | ||
| --cores <value-for-cpu> \// <5> | ||
| --infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \// <6> | ||
| --infra-kubeconfig-file=<path-to-external-infra-kubeconfig> <7> | ||
| --name <hosted-cluster-name> \ | ||
| --node-pool-replicas <worker-count> \ | ||
| --pull-secret <path-to-pull-secret> \ | ||
| --memory <value-for-memory> \ | ||
| --cores <value-for-cpu> \ | ||
| --infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \ | ||
| --infra-kubeconfig-file=<path-to-external-infra-kubeconfig> | ||
| ---- | ||
| + | ||
| <1> Specify the name of your hosted cluster, for example, `my-hosted-cluster`. | ||
| <2> Specify the worker count, for example, `2`. | ||
| <3> Specify the path to your pull secret, for example, `/user/name/pullsecret`. | ||
| <4> Specify a value for memory, for example, `6Gi`. | ||
| <5> Specify a value for CPU, for example, `2`. | ||
| <6> Specify the infrastructure namespace, for example, `clusters-example`. | ||
| <7> Specify the path to your `kubeconfig` file for the infrastructure cluster, for example, `/user/name/external-infra-kubeconfig`. | ||
| -- | ||
| ** `--name` defines the name of your hosted cluster, for example, `my-hosted-cluster`. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sometimes we use two asterisks at the beginning like here, sometimes we use just one (like in modules/hcp-virt-create-hc-cli.adoc. Is this intentional? Does it matter? Thanks
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mgencur Good question! The number of asterisks indicates how indented the list is. This list has two asterisks because it's nested under an unordered list item (the asterisk on line 31).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK. Thanks |
||
| ** `--node-pool-replicas` defines the worker count, for example, `2`. | ||
| ** `--pull-secret` defines the path to your pull secret, for example, `/user/name/pullsecret`. | ||
| ** `--memory` defines a value for memory, for example, `6Gi`. | ||
| ** `--cores` defines a value for CPU, for example, `2`. | ||
| ** `--infra-namespace` defines the infrastructure namespace, for example, `clusters-example`. | ||
| ** `--infra-kubeconfig-file` defines the path to your `kubeconfig` file for the infrastructure cluster, for example, `/user/name/external-infra-kubeconfig`. | ||
| -- | ||
| + | ||
| After you enter that command, the control plane pods are hosted on the management cluster that the HyperShift Operator runs on, and the KubeVirt VMs are hosted on a separate infrastructure cluster. | ||
| After you enter the command, the control plane pods are hosted on the management cluster that the HyperShift Operator runs on, and the KubeVirt VMs are hosted on a separate infrastructure cluster. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. moved |
||

Uh oh!
There was an error while loading. Please reload this page.