Skip to content

Commit 2a20bfa

Browse files
authored
Merge pull request #28714 from stoobie/OCPRHV-420-master
OCPRHV-420-master Added section on creating machine sets on OCP on RHV
2 parents 4c367a2 + 6b3234e commit 2a20bfa

File tree

4 files changed

+131
-1
lines changed

4 files changed

+131
-1
lines changed

_topic_map.yml

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1428,8 +1428,14 @@ Topics:
14281428
File: creating-machineset-gcp
14291429
- Name: Creating a machine set on OpenStack
14301430
File: creating-machineset-osp
1431+
- Name: Creating a machine set on RHV
1432+
File: creating-machineset-rhv
1433+
Distros: openshift-enterprise,openshift-webscale
1434+
- Name: Creating a machine set on oVirt
1435+
File: creating-machineset-rhv
1436+
Distros: openshift-origin
14311437
- Name: Creating a machine set on vSphere
1432-
File: creating-machineset-vsphere
1438+
File: creating-machineset-vsphere
14331439
- Name: Manually scaling a machine set
14341440
File: manually-scaling-machineset
14351441
- Name: Modifying a machine set
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
[id="creating-machineset-rhv"]
2+
= Creating a machine set on {rh-virtualization}
3+
include::modules/common-attributes.adoc[]
4+
:context: creating-machineset-rhv
5+
6+
You can create a different machine set to serve a specific purpose in your {product-title} cluster on {rh-virtualization-first}. For example, you might create infrastructure machine sets and related machines so that you can move supporting workloads to the new machines.
7+
8+
toc::[]
9+
10+
include::modules/machine-api-overview.adoc[leveloffset=+1]
11+
12+
include::modules/machineset-yaml-rhv.adoc[leveloffset=+1]
13+
14+
include::modules/machineset-creating.adoc[leveloffset=+1]

modules/machineset-creating.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -188,8 +188,10 @@ Review the command output and confirm that `node-role.kubernetes.io/<your_label>
188188
Any change to a machine set is not applied to existing machines owned by the machine set. For example, labels edited or added to an existing machine set are not propagated to existing machines and nodes associated with the machine set.
189189
====
190190

191+
ifeval::["{context}" == "creating-machineset-aws"]
191192
.Next steps
192193
If you need machine sets in other availability zones, repeat this process to create more machine sets.
194+
endif::[]
193195

194196
ifeval::["{context}" == "creating-machineset-vsphere"]
195197
:!vsphere:

modules/machineset-yaml-rhv.adoc

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * machine_management/creating-infrastructure-machinesets.adoc
4+
// * machine_management/creating_machinesets/creating-machineset-rhv.adoc
5+
6+
[id="machineset-yaml-rhv_{context}"]
7+
= Sample YAML for a machine set custom resource on {rh-virtualization}
8+
9+
This sample YAML defines a machine set that runs on {rh-virtualization} and creates nodes that are labeled with `node-role.kubernetes.io/<node_role>: ""`.
10+
11+
In this sample, `<infrastructure_id>` is the infrastructure ID label that is based on the cluster ID that you set when you provisioned the cluster, and `<role>` is the node label to add.
12+
13+
[source,yaml,subs="+quotes"]
14+
----
15+
apiVersion: machine.openshift.io/v1beta1
16+
kind: MachineSet
17+
metadata:
18+
labels:
19+
machine.openshift.io/cluster-api-cluster: <infrastructure_id> <1>
20+
machine.openshift.io/cluster-api-machine-role: <role> <2>
21+
machine.openshift.io/cluster-api-machine-type: <role> <2>
22+
name: <infrastructure_id>-<role> <3>
23+
namespace: openshift-machine-api
24+
spec:
25+
replicas: <number_of_replicas> <4>
26+
Selector: <5>
27+
matchLabels:
28+
machine.openshift.io/cluster-api-cluster: <infrastructure_id> <1>
29+
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> <3>
30+
template:
31+
metadata:
32+
labels:
33+
machine.openshift.io/cluster-api-cluster: <infrastructure_id> <1>
34+
machine.openshift.io/cluster-api-machine-role: <role> <2>
35+
machine.openshift.io/cluster-api-machine-type: <role> <2>
36+
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> <3>
37+
spec:
38+
metadata:
39+
labels:
40+
node-role.kubernetes.io/<role>: "" <2>
41+
providerSpec:
42+
value:
43+
apiVersion: ovirtproviderconfig.machine.openshift.io/v1beta1
44+
cluster_id: <ovirt_cluster_id> <6>
45+
template_name: <ovirt_template_name> <7>
46+
instance_type_id: <instance_type_id> <8>
47+
cpu: <9>
48+
sockets: <number_of_sockets> <10>
49+
cores: <number_of_cores> <11>
50+
threads: <number_of_threads> <12>
51+
memory_mb: <memory_size> <13>
52+
os_disk: <14>
53+
size_gb: <disk_size> <15>
54+
network_interfaces: <16>
55+
vnic_profile_id: <vnic_profile_id> <17>
56+
credentialsSecret:
57+
name: ovirt-credentials <18>
58+
kind: OvirtMachineProviderSpec
59+
type: <workload_type> <19>
60+
userDataSecret:
61+
name: worker-user-data
62+
----
63+
<1> Specify the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. If you have the OpenShift CLI (`oc`) installed, you can obtain the infrastructure ID by running the following command:
64+
+
65+
[source,terminal]
66+
----
67+
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
68+
----
69+
70+
<2> Specify the node label to add.
71+
72+
<3> Specify the infrastructure ID and node label. These two strings together cannot be longer than 35 characters.
73+
74+
<4> Specify the number of machines to create.
75+
76+
<5> Selector for the machines.
77+
78+
<6> Specify the UUID for the {rh-virtualization} cluster to which this VM instance belongs.
79+
80+
<7> Specify the {rh-virtualization} VM template to use to create the machine.
81+
82+
<8> Optional: Specify the VM instance type. If you include this parameter, you do not need to specify the hardware parameters of the VM including CPU and memory because this parameter overrides all hardware parameters.
83+
84+
<9> Optional: The CPU field contains the CPU's configuration, including sockets, cores, and threads.
85+
86+
<10> Optional: Specify the number of sockets for a VM.
87+
88+
<11> Optional: Specify the number of cores per socket.
89+
90+
<12> Optional: Specify the number of threads per core.
91+
92+
<13> Optional: Specify the size of a VM's memory in MiB.
93+
94+
<14> Optional: Root disk of the node.
95+
96+
<15> Optional: Specify the size of the bootable disk in GiB.
97+
98+
<16> Optional: List of the network interfaces of the VM. If you include this parameter, {product-title} discards all network interfaces from the template and creates new ones.
99+
100+
<17> Optional: Specify the vNIC profile ID.
101+
102+
<18> Specify the name of the secret that holds the {rh-virtualization} credentials.
103+
<19> Optional: Specify the workload type for which the instance is optimized. This value affects the `{rh-virtualization} VM` parameter. Supported values: `desktop`, `server`, `high_performance`.
104+
105+
[NOTE]
106+
====
107+
Because {rh-virtualization} uses a template when creating a VM, if you do not specify a value for an optional parameter, {rh-virtualization} uses the value for that parameter that is specified in the template.
108+
====

0 commit comments

Comments
 (0)