Merge pull request #42690 from johnwilkins/TELCODOCS-243-QE

TELCODOCS-243: D/S Docs & RN: METAL-6 (MPHARDWARE-4/KNIDEPLOY-2108) BIOS Settings Configuration (set values)

Author: skrthomas

modules/bmo-about-the-firmwareschema-resource.adoc

@@ -6,8 +6,7 @@
 [id="about-the-firmwareschema-resource_{context}"]
 = About the FirmwareSchema resource
 
-BIOS settings vary among hardware vendors and host models. A `FirmwareSchema` resource is a read-only resource that contains the types and limits for each BIOS setting on each host model. The data comes directly from the BMC through Ironic. The `FirmwareSchema` prevents you from sending invalid values to a host when specifying values in the `spec` field of the `HostFirmwareSettings` resource. The `FirmwareSchema` resource has a unique identifier derived from its settings and limits. Identical host models use the same `FirmwareSchema` identifier. It is likely that multiple instances of `HostFirmwareSettings` use the same `FirmwareSchema`.
-
+BIOS settings vary among hardware vendors and host models. A `FirmwareSchema` resource is a read-only resource that contains the types and limits for each BIOS setting on each host model. The data comes directly from the BMC through Ironic. The `FirmwareSchema` enables you to identify valid values you can specify in the `spec` field of the `HostFirmwareSettings` resource. The `FirmwareSchema` resource has a unique identifier derived from its settings and limits. Identical host models use the same `FirmwareSchema` identifier. It is likely that multiple instances of `HostFirmwareSettings` use the same `FirmwareSchema`.
 
 .FirmwareSchema specification
 [options="header"]

modules/bmo-about-the-hostfirmwaresettings-resource.adoc

@@ -15,7 +15,7 @@ The `HostFirmwareSettings` resource contains two sections:
 
 == The `HostFirmwareSettings` spec
 
-The `spec` section of the `HostFirmwareSettings` resource defines the desired state of the host's BIOS, and it is empty by default. Ironic uses the settings in the `spec.settings` section to update the baseboard management controller (BMC) when the host is in the `Preparing` state. The `spec.settings` section uses the `FirmwareSchema` resource schema to ensure that you do not send invalid name/value pairs to hosts. See "About the FirmwareSchema resource" for additional details.
+The `spec` section of the `HostFirmwareSettings` resource defines the desired state of the host's BIOS, and it is empty by default. Ironic uses the settings in the `spec.settings` section to update the baseboard management controller (BMC) when the host is in the `Preparing` state. Use the `FirmwareSchema` resource to ensure that you do not send invalid name/value pairs to hosts. See "About the FirmwareSchema resource" for additional details.
 
 .Example
 [source,terminal]

modules/bmo-editing-the-hostfirmwaresettings-resource.adoc

@@ -8,9 +8,14 @@
 
 You can edit the `HostFirmwareSettings` of provisioned hosts.
 
+[IMPORTANT]
+====
+You can only edit hosts in the `provisioned` state. You cannot edit values for hosts in the `externally provisioned` state. You cannot set read-only values.
+====
+
 .Procedure
 
-. Get the list of hosts:
+. Get the list of `HostFirmwareSettings` resources:
 +
 [source,terminal]
 ----
@@ -21,7 +26,7 @@ $ oc get hfs -n openshift-machine-api
 +
 [source,terminal]
 ----
-$ oc edit hfs -n openshift-machine-api/<host_name>
+$ oc edit hfs <host_name> -n openshift-machine-api
 ----
 +
 Where `<host_name>` is the name of a provisioned host. The `HostFirmwareSettings` resource will open in the default editor for your terminal.
@@ -33,7 +38,58 @@ Where `<host_name>` is the name of a provisioned host. The `HostFirmwareSettings
 ----
 spec:
   settings:
-    name: value
+    name: value <1>
 ----
+<1> Use the `FirmwareSchema` resource to identify the available settings for the host. You cannot set values that are read-only.
 
 . Save the changes and exit the editor.
+
+. Get the host's machine name:
++
+[source,terminal]
+----
+ $ oc get bmh <host_name> -n openshift-machine name
+----
++
+Where `<host_name>` is the name of the host. The machine name appears under the `CONSUMER` field.
+
+. Annotate the machine to delete it from the machineset:
++
+[source,terminal]
+----
+$ oc annotate machine <machine_name> machine.openshift.io/cluster-api-delete-machine=yes -n openshift-machine-api
+----
++
+Where `<machine_name>` is the name of the machine to delete.
+
+. Get a list of nodes and count the number of worker nodes:
++
+[source,terminal]
+----
+$ oc get nodes
+----
+
+. Get the machineset:
++
+[source,terminal]
+----
+$ oc get machinesets -n openshift-machine-api
+----
+
+. Scale the machineset:
++
+[source,terminal]
+----
+$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
+----
++
+Where `<machineset_name>` is the name of the machineset and `<n-1>` is the decremented number of worker nodes.
+
+. When the host enters the `Available` state, scale up the machineset to make the `HostFirmwareSettings` resource changes take effect:
++
+[source,terminal]
+----
+$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
+----
++
+Where `<machineset_name>` is the name of the machineset and `<n>` is the number of worker nodes.

modules/bmo-getting-the-baremetalhost-resource.adoc

@@ -9,7 +9,7 @@ The `BareMetalHost` resource contains the properties of a physical host. You mus
 
 .Procedure
 
-. Get the `BareMetalHost` resource for all hosts:
+. Get the list of `BareMetalHost` resources:
 +
 [source,terminal]
 ----
@@ -28,11 +28,11 @@ You can use `baremetalhost` as the long form of `bmh` with `oc get` command.
 $ oc get bmh -n openshift-machine-api
 ----
 
-. Get the `BareMetalHost` resource for a specific host
+. Get the `BareMetalHost` resource for a specific host:
 +
 [source,terminal]
 ----
-$ oc get bmh -n openshift-machine-api/<host_name> -o yaml
+$ oc get bmh <host_name> -n openshift-machine-api -o yaml
 ----
 +
 Where `<host_name>` is the name of the host.

modules/bmo-getting-the-firmwareschema-resource.adoc

@@ -21,7 +21,7 @@ $ oc get firmwareschema -n openshift-machine-api
 +
 [source,terminal]
 ----
-$ oc get firmwareschema -n openshift-machine-api/<instance_name> -o yaml
+$ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
 ----
 +
-Where `<instance_name>` is the name of the schema instance.
+Where `<instance_name>` is the name of the schema instance stated in the `HostFirmwareSettings` resource (see Table 3).

modules/bmo-getting-the-hostfirmwaresettings-resource.adoc

@@ -9,7 +9,7 @@ The `HostFirmwareSettings` resource contains the vendor-specific BIOS properties
 
 .Procedure
 
-. Get the detailed list of the `HostFirmwareSettings` resource settings:
+. Get the detailed list of `HostFirmwareSettings` resources:
 +
 [source,terminal]
 ----
@@ -21,7 +21,7 @@ $ oc get hfs -n openshift-machine-api -o yaml
 You can use `hostfirmwaresettings` as the long form of `hfs` with the `oc get` command.
 ====
 
-. Get the list of hosts:
+. Get the list of `HostFirmwareSettings` resources:
 +
 [source,terminal]
 ----
@@ -32,7 +32,7 @@ $ oc get hfs -n openshift-machine-api
 +
 [source,terminal]
 ----
-$ oc get hfs -n openshift-machine-api/<host_name> -o yaml
+$ oc get hfs <host_name> -n openshift-machine-api -o yaml
 ----
 +
 Where `<host_name>` is the name of the host.

modules/bmo-verifying-the-hostfirmware-settings-resource-is-valid.adoc

@@ -10,7 +10,7 @@ When the user edits the `spec.settings` section to make a change to the `HostFir
 
 .Procedure
 
-. Get a list of hosts:
+. Get a list of `HostFirmwareSetting` resources:
 +
 [source,terminal]
 ----
@@ -21,7 +21,7 @@ $ oc get hfs -n openshift-machine-api
 +
 [source,terminal]
 ----
-$ oc describe hfs/<host_name> -n openshift-machine-api
+$ oc describe hfs <host_name> -n openshift-machine-api
 ----
 +
 Where `<host_name>` is the name of the host.

modules/ipi-install-provisioning-the-bare-metal-node.adoc

@@ -12,45 +12,44 @@ Provisioning the bare metal node requires executing the following procedure from
 
 . Ensure the `STATE` is `available` before provisioning the bare metal node.
 +
-[source,bash]
+[source,terminal]
 ----
 $  oc -n openshift-machine-api get bmh openshift-worker-<num>
 ----
 +
 Where `<num>` is the worker node number.
 +
-[source,bash]
+[source,terminal]
 ----
-NAME                     STATE      CONSUMER     ONLINE   ERROR
-openshift-worker-<num>   available               true
+NAME              STATE     ONLINE ERROR  AGE
+openshift-worker  available true          34h
 ----
 
 . Get a count of the number of worker nodes.
-[source,bash]
+[source,terminal]
 +
 ----
 $ oc get nodes
 ----
 +
-[source,bash]
+[source,terminal]
 ----
 NAME                                                STATUS   ROLES           AGE     VERSION
-provisioner.openshift.example.com                   Ready    master          30h     v1.23.0
 openshift-master-1.openshift.example.com            Ready    master          30h     v1.23.0
 openshift-master-2.openshift.example.com            Ready    master          30h     v1.23.0
 openshift-master-3.openshift.example.com            Ready    master          30h     v1.23.0
-openshift-worker-0.openshift.example.com            Ready    master          30h     v1.23.0
-openshift-worker-1.openshift.example.com            Ready    master          30h     v1.23.0
+openshift-worker-0.openshift.example.com            Ready    worker          30h     v1.23.0
+openshift-worker-1.openshift.example.com            Ready    worker          30h     v1.23.0
 ----
 
 . Get the machine set.
 +
-[source,bash]
+[source,terminal]
 ----
 $ oc get machinesets -n openshift-machine-api
 ----
 +
-[source,bash]
+[source,terminal]
 ----
 NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
 ...
@@ -60,7 +59,7 @@ openshift-worker-1.example.com      1         1         1       1           55m
 
 . Increase the number of worker nodes by one.
 +
-[source,bash]
+[source,terminal]
 ----
 $ oc scale --replicas=<num> machineset <machineset> -n openshift-machine-api
 ----
@@ -69,54 +68,53 @@ Replace `<num>` with the new number of worker nodes. Replace `<machineset>` with
 
 . Check the status of the bare metal node.
 +
-[source,bash]
+[source,terminal]
 ----
 $ oc -n openshift-machine-api get bmh openshift-worker-<num>
 ----
 +
-Where `<num>` is the worker node number. The `STATE` changes from `available` to `provisioning`.
+Where `<num>` is the worker node number. The STATE changes from `ready` to `provisioning`.
 +
-[source,bash]
+[source,terminal]
 ----
 NAME                    STATE             CONSUMER                          ONLINE   ERROR
 openshift-worker-<num>  provisioning      openshift-worker-<num>-65tjz      true
 ----
 +
 The `provisioning` status remains until the {product-title} cluster provisions the node. This can take 30 minutes or more. After the node is provisioned, the state will change to `provisioned`.
 +
-[source,bash]
+[source,terminal]
 ----
 NAME                    STATE             CONSUMER                          ONLINE   ERROR
-openshift-worker-<num>  provisioning      openshift-worker-<num>-65tjz      true
+openshift-worker-<num>  provisioned       openshift-worker-<num>-65tjz      true
 ----
 
 . After provisioning completes, ensure the bare metal node is ready.
 +
-[source,bash]
+[source,terminal]
 ----
 $ oc get nodes
 ----
 +
-[source,bash]
+[source,terminal]
 ----
 NAME                                          STATUS   ROLES   AGE     VERSION
-provisioner.openshift.example.com             Ready    master  30h     v1.23.0
 openshift-master-1.openshift.example.com      Ready    master  30h     v1.23.0
 openshift-master-2.openshift.example.com      Ready    master  30h     v1.23.0
 openshift-master-3.openshift.example.com      Ready    master  30h     v1.23.0
-openshift-worker-0.openshift.example.com      Ready    master  30h     v1.23.0
-openshift-worker-1.openshift.example.com      Ready    master  30h     v1.23.0
+openshift-worker-0.openshift.example.com      Ready    worker  30h     v1.23.0
+openshift-worker-1.openshift.example.com      Ready    worker  30h     v1.23.0
 openshift-worker-<num>.openshift.example.com  Ready    worker  3m27s   v1.23.0
 ----
 +
 You can also check the kubelet.
 +
-[source,bash]
+[source,terminal]
 ----
 $ ssh openshift-worker-<num>
 ----
 +
-[source,bash]
+[source,terminal]
 ----
 [kni@openshift-worker-<num>]$ journalctl -fu kubelet
 ----

post_installation_configuration/bare-metal-configuration.adoc

@@ -11,7 +11,7 @@ When deploying {product-title} on bare metal hosts, there are times when you nee
 * `BareMetalHost`
 * `HostFirmwareSettings`
 
-There is also a read-only `FirmwareSchema` resource, which you can use to validate that you are sending correct values to a host when making changes to host firmware settings.
+There is also a read-only `FirmwareSchema` resource, which you can use to determine the valid values that you can send to a host when making changes to host firmware settings.
 
 include::modules/bmo-about-the-baremetalhost-resource.adoc[leveloffset=+1]
 include::modules/bmo-getting-the-baremetalhost-resource.adoc[leveloffset=+1]