fix spellcheck issues

Fix newly found spellcheck issues. These were uncovered by the config
fix in previous commit.

Signed-off-by: Tuomo Tanskanen <[email protected]>

.cspell-config.json

@@ -35,6 +35,7 @@
     "BMH",
     "BMHs",
     "BMO",
+    "bootable",
     "BR",
     "CABPK",
     "CAPBM",
@@ -65,26 +66,35 @@
     "deprovision",
     "deprovisioning",
     "dev",
+    "dhcpd",
     "DIR",
-    "Dnsmasq",
+    "Dmitry",
     "dnsmasq",
     "drac",
     "EKS",
+    "elfosardo",
     "endpoint",
     "entrypoint",
     "env",
     "ethernets",
     "F5",
     "filesystem",
+    "finalizer",
     "foo",
     "GB",
+    "gibibytes",
     "GitHub",
+    "godoc",
     "golang",
     "google",
     "gophercloud",
     "gRPC",
+    "hctl",
+    "healthcheck",
     "Hellmann",
     "hostname",
+    "HWCC",
+    "idrac",
     "initramfs",
     "Interop",
     "IO",
@@ -97,6 +107,7 @@
     "IPPool",
     "iptables",
     "iPXE",
+    "ironicendpoint",
     "iso",
     "Jern",
     "js",
@@ -110,6 +121,7 @@
     "KubeadmConfig",
     "KubeadmConfigTemplate",
     "KubeadmControlPlane",
+    "kubebuilder",
     "KubeCon",
     "kubeconfig",
     "kubectl",
@@ -123,15 +135,16 @@
     "Lennart",
     "libvirt",
     "lifecycle",
+    "LLDP",
     "MachineDeployment",
     "MachineDeployments",
-    "MachineSet back",
     "MachineSet",
     "machinesets",
     "maintainers",
     "markdown",
     "md",
     "mdbook",
+    "mebibytes",
     "meetup",
     "meetups",
     "meta",
@@ -142,6 +155,7 @@
     "Metal3DataTemplate",
     "Metal3Machine",
     "Metal3MachineTemplate",
+    "microversion",
     "minikube",
     "Mitigations",
     "MM",
@@ -153,6 +167,7 @@
     "NICs",
     "nodepool",
     "Nordix",
+    "nvme",
     "OCI",
     "OpenShift",
     "OpenStack",
@@ -161,49 +176,61 @@
     "ownerReferences",
     "passwordless",
     "periodics",
+    "Pittau",
     "playbook",
     "playbooks",
     "PM",
     "podman",
     "PowerEdge",
     "preconfigured",
+    "preprovisioning",
     "provisioner",
     "provisioners",
     "PRs",
     "PVC",
     "PVCs",
     "PXE",
     "QCOW",
-    "qe",
     "QE",
     "QEMU",
+    "quickstart",
     "ramdisk",
     "Redfish",
+    "releasetag",
     "repo",
-    "REPO",
     "reprovision",
     "reprovisioning",
+    "Riccardo",
     "roadmap",
+    "Rozman",
     "rsa",
     "runhttpd",
+    "schedulable",
     "scu",
     "sdk",
     "service.d",
     "sh",
     "SIG",
     "SLAAC",
+    "snmp",
     "sourced",
     "SR",
     "ssh",
+    "struct",
     "subresource",
     "sudo",
+    "Supermicro",
     "sushy",
-    "SUSHY",
+    "Tanskanen",
+    "Tantsur",
     "TLS",
     "tripleo",
-    "UI a",
+    "Tuomo",
+    "UEFI",
     "UI",
     "UID",
+    "unmanaged",
+    "unmarshal",
     "Unported",
     "vars",
     "VBMC",
@@ -213,8 +240,6 @@
     "virtualization",
     "Virtualmedia",
     "VLANs",
-    "VM are",
-    "VM as",
     "VM",
     "VMs",
     "VRRP",
@@ -228,7 +253,7 @@
     "yaml",
     "YAML",
     "youtube",
-    "Youtube",
+    "zaneb",
     "zoomable"
   ]
 }

README.md

@@ -8,6 +8,8 @@
 
 ## What is Metal³
 
+<!-- cSpell:ignore Kubed -->
+
 The Metal³ project (pronounced: Metal Kubed) exists to provide components that
 allow you to do bare metal host management for Kubernetes.  Metal³ works as a
 Kubernetes application, meaning it runs on Kubernetes and is managed through
@@ -37,7 +39,7 @@ come talk to us!
   google group for the edit access to the
   [Community meetings Notes](https://docs.google.com/document/d/1IkEIh-ffWY3DaNX3aFcAxGbttdEY_symo7WAGmzkWhU/edit)
 * Subscribe to the [Metal³ Development Mailing List](https://groups.google.com/forum/#!forum/metal3-dev)
-  for the project related anouncements, discussions and questions.
+  for the project related announcements, discussions and questions.
 * Come and meet us in our weekly community meetings on every
   Wednesday at 14:00 UTC on [Zoom](https://zoom.us/j/97255696401?pwd=ZlJMckNFLzdxMDNZN2xvTW5oa2lCZz09)
 * If you missed the previous community meeting, you can still find the notes

design/baremetal-operator/annotation-for-power-cycling-and-deleting-failed-nodes.md

@@ -43,12 +43,12 @@ several) does not put additional stress on surviving peers, however budget
 constraints mean that this is often not the case, particularly in Edge
 deployments which may consist of as few as three nodes of commodity hardware.
 Even when deployments start off over-provisioned, there is a tendency for the
-extra capacity to become permanently utilised.  It is therefore usually
+extra capacity to become permanently utilized. It is therefore usually
 important to recover the lost capacity quickly.
 
 For this reason it is desirable to power the machine back on again, in the hope
 that the problem was transient and the node can return to a healthy state.
-Upon restarting, kubelet automatically contacts the masters to re-register
+Upon restarting, Kubelet automatically contacts the masters to re-register
 itself, allowing it to host workloads.
 
 ### Goals
@@ -108,7 +108,7 @@ See [PoC code](https://github.com/kubevirt/machine-remediation/)
 - Two new controllers:
    - [node
     reboot](https://github.com/kubevirt/machine-remediation/tree/master/pkg/controllers/nodereboot)
-    which looks for the annoation and creates Machine Remediation CRs
+    which looks for the annotation and creates Machine Remediation CRs
    - [machine
     remediation](https://github.com/kubevirt/machine-remediation/tree/master/pkg/controllers/machineremediation)
     which reboots the machine and deletes the Node object (which also
@@ -118,12 +118,12 @@ See [PoC code](https://github.com/kubevirt/machine-remediation/)
 ### Work Items
 
 - Make any requested modifications
-- Create a PR from github.com/kubevirt/machine-remediation into
-  github.com/metal3-io/cluster-api-provider-baremetal
+- Create a PR from [KubeVirt](github.com/kubevirt/machine-remediation)
+  into [CAPM3](github.com/metal3-io/cluster-api-provider-baremetal)
 
 ### Dependencies
 
-This design is intended to integrate with OpenShift’s [Machine Healthcheck
+This design is intended to integrate with OpenShift’s [Machine HealthCheck
 implementation](https://github.com/openshift/machine-api-operator/blob/master/pkg/controller/machinehealthcheck/machinehealthcheck_controller.go#L407)
 
 ### Test Plan
@@ -137,22 +137,22 @@ non-functional or inaccessible.
 ### Upgrade / Downgrade Strategy
 
 The added functionality is inert without external input.
-No changes are required to preserve the existing behaviour.
+No changes are required to preserve the existing behavior.
 
 ### Version Skew Strategy
 
-By shipping the new controller with the baremetal-operator that it consumes, we
+By shipping the new controller with the BareMetal Operator that it consumes, we
 can prevent any version mismatches.
 
 ## Drawbacks
 
-Baremetal is currently the only platform looking to implement this feature, so
+Bare metal is currently the only platform looking to implement this feature, so
 any implementation is necessarily non-standard.
 
 If other platforms come to see value in power based recovery, there may need to
 design a different or more formal signaling method (than an annotation) as well
 as decompose the implementation into discrete units that can live behind a
-platform independant interface such as the Machine or Cluster APIs.
+platform independent interface such as the Machine or Cluster APIs.
 
 ## Alternatives
 

design/baremetal-operator/bmc-events.md

@@ -52,14 +52,16 @@ threshold.
 - I'd like to configure my BMC to send events to a destination URI.
 - I'd like to provide context to a particular event subscription.
 - I'd like to provide arbitrary HTTP headers
-- I'd like the baremetal-operator to reconcile on the
+- I'd like the BareMetal Operator to reconcile on the
   BMCEventSubscription resource, and ensure its state is accurate in
   Ironic.
 
 ## Design Details
 
 ### Implementation Details
 
+<!-- cSpell:ignore ostest -->
+
 ```yaml
 apiVersion: metal3.io/v1alpha1
 kind: BMCEventSubscription
@@ -79,15 +81,15 @@ status:
 
 - A BMCEventSubscription resource represents a subscription to the events generated
   by a specific BMC.
-- Ironic will manage configuring the subscription using a vendor passthru API.
+- Ironic will manage configuring the subscription using a vendor passthrough API.
 - The BMCEventSubscription will maintain a reference to a BareMetalHost.
 - The BMCEventSubscription will allow injection of headers using a
   reference to a secret, for example to provide basic auth credentials.
 - The BMCEventSubscription will reside in the same namespace as the referenced
   BareMetalHost.
 - The BMCEventSubscription will maintain a reference to the subscription ID
   obtained from the BMC.
-- The baremetal-operator binary will be expanded to include an additional
+- The BareMetal Operator binary will be expanded to include an additional
   reconciler with a dedicated controller/reconcile loop for
   BMCEventSubscriptions.
 
@@ -125,7 +127,7 @@ alert that monitors the enclosure's temperature.
 The Redfish standard itself does not seem to have a way to specify
 specific alerts and thresholds. For example, to receive an alert when
 the temperature exceeds 40C, one would need to configure this manually
-according to the vendor's reccomendations.
+according to the vendor's recommendations.
 
 Vendors, however, do provide vendor-specific ways to configure these
 thresholds, but it's hard to abstract to a neutral interface. For
@@ -136,7 +138,9 @@ implementations (if they exist at all).
 
 ## References
 
-- [Ironic Vendor Passthru for Subscriptions](https://storyboard.openstack.org/#!/story/2009061)
+<!-- cSpell:ignore Supermicro,DMTF -->
+
+- [Ironic Vendor Passthrough for Subscriptions](https://storyboard.openstack.org/#!/story/2009061)
 - [Supermicro Redfish Guide](https://www.supermicro.com/manuals/other/RedfishRefGuide.pdf)
 - [DMTF: Redfish Eventing](https://www.dmtf.org/sites/default/files/Redfish%20School%20-%20Events.pdf)
 - [Redfish Event Controller (POC)](https://github.com/dhellmann/redfish-event-controller)

design/baremetal-operator/bmh_live_iso.md

@@ -7,6 +7,8 @@
 
 # Add boot-iso API to BareMetalHost
 
+<!-- cSpell:ignore efibootmgr,fcos -->
+
 ## Status
 
 implemented
@@ -123,6 +125,6 @@ is probably reasonable.
 
 We could avoid exposing this interface and mandate all users rely on IPA to
 deploy disk images, but this doesn't provide a good solution for the
-emphemeral worload case, and requires testing/supporting two install paths
+ephemeral workload case, and requires testing/supporting two install paths
 where a platform (such as FCOS mentioned) provides existing iso based
 tooling to deploy to disk.

design/baremetal-operator/bmh_non-bootable_iso.md

@@ -68,7 +68,7 @@ has been Provisioned or ExternallyProvisioned.
 
 ### Ironic Support
 
-The [proposal](https://bugs.launchpad.net/ironic/+bug/2033288) for exposing this functionaility in Ironic has been
+The [proposal](https://bugs.launchpad.net/ironic/+bug/2033288) for exposing this functionality in Ironic has been
 accepted by the upstream Ironic community.
 
 The [Ironic implementation](https://review.opendev.org/c/openstack/ironic/+/894918) based on the above proposal has been completed.

design/baremetal-operator/bmo-ci-decoupling.md

@@ -43,7 +43,7 @@ As a next step, the following proposal is made for the branching:
   Instead of using tags which is the way we test currently, we can use branch
   names for specific branches of CAPM3. For example, CAPM3 release-1.5 branch
   will be tested with BMO release-0.4 branch and CAPM3 main branch will be
-  tested with BMO main branch. Releasings and branch maintenance is desribed in
+  tested with BMO main branch. Releasing and branch maintenance is described in
   BMO [releasing document](https://github.com/metal3-io/baremetal-operator/blob/main/docs/releasing.md)
 
 - Release  process for BMO need to have proper documentation or uplift

design/baremetal-operator/bmo-part-of-capm3.md

@@ -1,5 +1,7 @@
 # Make Bare Metal Operator as part of Cluster API Provider Metal3
 
+<!-- cSpell:ignore bmopath -->
+
 The end goal behind making Bare Metal Operator(BMO) as part of Cluster
 API Provider Metal3(CAPM3) is to use
 [clusterctl](https://cluster-api.sigs.k8s.io/clusterctl/commands/move.html)

design/baremetal-operator/bulk-set-bios-config.md

@@ -7,6 +7,8 @@
 
 # bulk-set-bios-config
 
+<!-- cSpell:ignore corev -->
+
 ## Status
 
 implementable
@@ -77,7 +79,7 @@ This proposal does not attempt to fulfill the following goals:
 - Keep the BIOS settings on similar hardware in sync automatically
   using an additional operator, although that functionality is planned
   for a follow-on
-- A future feature is planned to make use of this funtionality to
+- A future feature is planned to make use of this functionality to
   automatically keep BIOS settings in sync on similar hardware using
   a new operator. This future will require a separate proposal and is out
   of scope for this proposal.
@@ -244,7 +246,7 @@ actions will be taken:
   a `namespace` hint will be added to the BMO to specify the namespace to
   use for the schema. These BMO changes will be described in a follow-on
   doc.
-- It is recommended that the refererence to the schema not use
+- It is recommended that the reference to the schema not use
   corev1.ObjectReference, but instead define a separate struct, see
   [ObjectReference](https://github.com/kubernetes-sigs/cluster-api/issues/2318)
 

design/baremetal-operator/deploy-steps.md

@@ -7,6 +7,8 @@
 
 # Customizable deployment procedure
 
+<!-- cSpell:ignore configdrive,footgun -->
+
 ## Status
 
 implemented