Merge pull request #63519 from amolnar-rh/TELCODOCS-1347

TELCODOCS-1347: Add support for node labels to SiteConfig

Author: opayne1

modules/ztp-deploying-a-site.adoc

@@ -88,3 +88,31 @@ For more information, see "Customizing extra installation manifests in the {ztp}
 . Commit the `SiteConfig` CR and associated `kustomization.yaml` changes in your Git repository and push the changes.
 +
 The ArgoCD pipeline detects the changes and begins the managed cluster deployment.
+
+.Verification
+
+* Verify that the custom roles and labels are applied after the node is deployed:
++
+[source,terminal]
+----
+$ oc describe node example-node.example.com
+----
+
+.Example output
+[source,terminal]
+----
+Name:   example-node.example.com
+Roles:  control-plane,example-label,master,worker
+Labels: beta.kubernetes.io/arch=amd64
+        beta.kubernetes.io/os=linux
+        custom-label/parameter1=true
+        kubernetes.io/arch=amd64
+        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
+        kubernetes.io/os=linux
+        node-role.kubernetes.io/control-plane=
+        node-role.kubernetes.io/example-label= <1>
+        node-role.kubernetes.io/master=
+        node-role.kubernetes.io/worker=
+        node.openshift.io/os_id=rhcos
+----
+<1> The custom label is applied to the node.

modules/ztp-generating-install-and-config-crs-manually.adoc

@@ -151,3 +151,31 @@ ref
 ----
 
 . Use the generated CRs as the basis for the CRs that you use to install the cluster. You apply the installation CRs to the hub cluster as described in "Installing a single managed cluster". The configuration CRs can be applied to the cluster after cluster installation is complete.
+
+.Verification
+
+* Verify that the custom roles and labels are applied after the node is deployed:
++
+[source,terminal]
+----
+$ oc describe node example-node.example.com
+----
+
+.Example output
+[source,terminal]
+----
+Name:   example-node.example.com
+Roles:  control-plane,example-label,master,worker
+Labels: beta.kubernetes.io/arch=amd64
+        beta.kubernetes.io/os=linux
+        custom-label/parameter1=true
+        kubernetes.io/arch=amd64
+        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
+        kubernetes.io/os=linux
+        node-role.kubernetes.io/control-plane=
+        node-role.kubernetes.io/example-label= <1>
+        node-role.kubernetes.io/master=
+        node-role.kubernetes.io/worker=
+        node.openshift.io/os_id=rhcos
+----
+<1> The custom label is applied to the node.

snippets/ztp-example-siteconfig.adoc

@@ -34,15 +34,18 @@ spec:
     nodes:
       - hostName: "example-node.example.com" <6>
         role: "master"
-        bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ <7>
+        nodeLabels: <7>
+          node-role.kubernetes.io/example-label:
+          custom-label/parameter1: true
+        bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ <8>
         bmcCredentialsName:
-          name: "bmh-secret" <8>
+          name: "bmh-secret" <9>
         bootMACAddress: "AA:BB:CC:DD:EE:11"
-        bootMode: "UEFI" <9>
-        rootDeviceHints: <10>
+        bootMode: "UEFI" <10>
+        rootDeviceHints: <11>
           wwn: "0x11111000000asd123"
-        cpuset: "0-1,52-53"  <11>
-        nodeNetwork: <12>
+        cpuset: "0-1,52-53"  <12>
+        nodeNetwork: <13>
           interfaces:
             - name: eno1
               macAddress: "AA:BB:CC:DD:EE:11"
@@ -53,7 +56,7 @@ spec:
                 state: up
                 ipv4:
                   enabled: false
-                ipv6: <13>
+                ipv6: <14>
                   enabled: true
                   address:
                   - ip: 1111:2222:3333:4444::aaaa:1
@@ -77,10 +80,11 @@ spec:
 <4> Cluster labels must correspond to the `bindingRules` field in the `PolicyGenTemplate` CRs that you define. For example, `policygentemplates/common-ranGen.yaml` applies to all clusters with `common: true` set, `policygentemplates/group-du-sno-ranGen.yaml` applies to all clusters with `group-du-sno: ""` set.
 <5> Optional. The CR specifed under `KlusterletAddonConfig` is used to override the default `KlusterletAddonConfig` that is created for the cluster.
 <6> For single-node deployments, define a single host. For three-node deployments, define three hosts. For standard deployments, define three hosts with `role: master` and two or more hosts defined with `role: worker`.
-<7> BMC address that you use to access the host. Applies to all cluster types. {ztp} supports iPXE and virtual media booting by using Redfish or IPMI protocols. To use iPXE booting, you must use {rh-rhacm} 2.8 or later. For more information about BMC addressing, see the _Additional resources_ section.
-<8> Name of the `bmh-secret` CR that you separately create with the host BMC credentials. When creating the `bmh-secret` CR, use the same namespace as the `SiteConfig` CR that provisions the host.
-<9> Configures the boot mode for the host. The default value is `UEFI`. Use `UEFISecureBoot` to enable secure boot on the host.
-<10> Specifies the device for deployment. Identifiers that are stable across reboots are recommended, for example `wwn: <disk_wwn>` or `deviceName: /dev/disk/by-path/<device_path>`. For a detailed list of stable identifiers, see the _About root device hints_ section.
-<11> `cpuset` must match the value set in the cluster `PerformanceProfile` CR `spec.cpu.reserved` field for workload partitioning.
-<12> Specifies the network settings for the node.
-<13> Configures the IPv6 address for the host. For {sno} clusters with static IP addresses, the node-specific API and Ingress IPs should be the same.
+<7> Specify custom roles to your nodes in your managed clusters. These are additional roles which are not used by any {product-title} components, only by the user. When you add a custom role, it can be associated with a custom machine config pool that references a specific configuration for that role. Adding your custom labels or roles during installation makes the deployment process more effective and prevents the need for additional reboots after the installation is complete.
+<8> BMC address that you use to access the host. Applies to all cluster types. {ztp} supports iPXE and virtual media booting by using Redfish or IPMI protocols. To use iPXE booting, you must use {rh-rhacm} 2.8 or later. For more information about BMC addressing, see the _Additional resources_ section.
+<9> Name of the `bmh-secret` CR that you separately create with the host BMC credentials. When creating the `bmh-secret` CR, use the same namespace as the `SiteConfig` CR that provisions the host.
+<10> Configures the boot mode for the host. The default value is `UEFI`. Use `UEFISecureBoot` to enable secure boot on the host.
+<11> Specifies the device for deployment. Identifiers that are stable across reboots are recommended, for example `wwn: <disk_wwn>` or `deviceName: /dev/disk/by-path/<device_path>`. For a detailed list of stable identifiers, see the _About root device hints_ section.
+<12> `cpuset` must match the value set in the cluster `PerformanceProfile` CR `spec.cpu.reserved` field for workload partitioning.
+<13> Specifies the network settings for the node.
+<14> Configures the IPv6 address for the host. For {sno} clusters with static IP addresses, the node-specific API and Ingress IP addresses must be the same.