openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

TELCODOCS-243-QE: Adds HostFirmwareSettings and FirmwareSchema resources..

Browse Source
This commit is contained in:
John Wilkins
2022-03-02 14:02:22 -08:00
committed by openshift-cherrypick-robot
parent 26e61975fe
commit 43c80a5e4e
9 changed files with 94 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
modules/bmo-about-the-firmwareschema-resource.adoc
View File

@@ -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"]

2
modules/bmo-about-the-hostfirmwaresettings-resource.adoc
View File

@@ -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]

62
modules/bmo-editing-the-hostfirmwaresettings-resource.adoc
View File

@@ -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.

6
modules/bmo-getting-the-baremetalhost-resource.adoc
View File

@@ -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.

4
modules/bmo-getting-the-firmwareschema-resource.adoc
View File

@@ -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).

6
modules/bmo-getting-the-hostfirmwaresettings-resource.adoc
View File

@@ -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.

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

@@ -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.

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

@@ -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,14 +68,14 @@ 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
@@ -84,39 +83,38 @@ 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
----

2
post_installation_configuration/bare-metal-configuration.adoc
View File

@@ -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]