diff --git a/.cspell-config.json b/.cspell-config.json index aa9ca2c6..32172144 100644 --- a/.cspell-config.json +++ b/.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,12 +176,14 @@ "ownerReferences", "passwordless", "periodics", + "Pittau", "playbook", "playbooks", "PM", "podman", "PowerEdge", "preconfigured", + "preprovisioning", "provisioner", "provisioners", "PRs", @@ -174,36 +191,46 @@ "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" ] } diff --git a/README.md b/README.md index 6dba22e3..08d5ef5b 100644 --- a/README.md +++ b/README.md @@ -8,6 +8,8 @@ ## What is Metal³ + + 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 diff --git a/design/baremetal-operator/annotation-for-power-cycling-and-deleting-failed-nodes.md b/design/baremetal-operator/annotation-for-power-cycling-and-deleting-failed-nodes.md index d5bd7c4f..c9089089 100644 --- a/design/baremetal-operator/annotation-for-power-cycling-and-deleting-failed-nodes.md +++ b/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 diff --git a/design/baremetal-operator/bmc-events.md b/design/baremetal-operator/bmc-events.md index a1b18726..1cb0bfa7 100644 --- a/design/baremetal-operator/bmc-events.md +++ b/design/baremetal-operator/bmc-events.md @@ -52,7 +52,7 @@ 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. @@ -60,6 +60,8 @@ threshold. ### Implementation Details + + ```yaml apiVersion: metal3.io/v1alpha1 kind: BMCEventSubscription @@ -79,7 +81,7 @@ 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. @@ -87,7 +89,7 @@ status: 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) + + +- [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) diff --git a/design/baremetal-operator/bmh_live_iso.md b/design/baremetal-operator/bmh_live_iso.md index 7535d501..e8f452d0 100644 --- a/design/baremetal-operator/bmh_live_iso.md +++ b/design/baremetal-operator/bmh_live_iso.md @@ -7,6 +7,8 @@ # Add boot-iso API to BareMetalHost + + ## 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. diff --git a/design/baremetal-operator/bmh_non-bootable_iso.md b/design/baremetal-operator/bmh_non-bootable_iso.md index e9fe1e92..0138662d 100644 --- a/design/baremetal-operator/bmh_non-bootable_iso.md +++ b/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. diff --git a/design/baremetal-operator/bmo-ci-decoupling.md b/design/baremetal-operator/bmo-ci-decoupling.md index bc946570..6d1dfae1 100644 --- a/design/baremetal-operator/bmo-ci-decoupling.md +++ b/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 diff --git a/design/baremetal-operator/bmo-part-of-capm3.md b/design/baremetal-operator/bmo-part-of-capm3.md index 51c428f6..d3b40801 100644 --- a/design/baremetal-operator/bmo-part-of-capm3.md +++ b/design/baremetal-operator/bmo-part-of-capm3.md @@ -1,5 +1,7 @@ # Make Bare Metal Operator as part of Cluster API Provider Metal3 + + 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) diff --git a/design/baremetal-operator/bulk-set-bios-config.md b/design/baremetal-operator/bulk-set-bios-config.md index 8d59ad1a..5f666b47 100644 --- a/design/baremetal-operator/bulk-set-bios-config.md +++ b/design/baremetal-operator/bulk-set-bios-config.md @@ -7,6 +7,8 @@ # bulk-set-bios-config + + ## 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) diff --git a/design/baremetal-operator/deploy-steps.md b/design/baremetal-operator/deploy-steps.md index 25b0e3f9..abc2be03 100644 --- a/design/baremetal-operator/deploy-steps.md +++ b/design/baremetal-operator/deploy-steps.md @@ -7,6 +7,8 @@ # Customizable deployment procedure + + ## Status implemented diff --git a/design/baremetal-operator/detached-annotation.md b/design/baremetal-operator/detached-annotation.md index 71d15064..64294940 100644 --- a/design/baremetal-operator/detached-annotation.md +++ b/design/baremetal-operator/detached-annotation.md @@ -106,6 +106,6 @@ We could add an API that sets the Ironic [maintenance mode flag](https://docs.openstack.org/api-ref/baremetal/?expanded=set-maintenance-flag-detail#set-maintenance-flag) but this means hosts could potentially permanently be in this state and there are concerns about corner-cases such as adoption when an -ephemeral Ironic is used and a rechedule occurs. +ephemeral Ironic is used and a reschedule occurs. ## References diff --git a/design/baremetal-operator/hardware-status.md b/design/baremetal-operator/hardware-status.md index 7c34fdd9..ca3fff02 100644 --- a/design/baremetal-operator/hardware-status.md +++ b/design/baremetal-operator/hardware-status.md @@ -7,6 +7,8 @@ # hardware-status + + ## Status provisional diff --git a/design/baremetal-operator/hardwaredata_crd.md b/design/baremetal-operator/hardwaredata_crd.md index 32bb0861..4d1b6556 100644 --- a/design/baremetal-operator/hardwaredata_crd.md +++ b/design/baremetal-operator/hardwaredata_crd.md @@ -1,5 +1,7 @@ # hardwareData custom resource for host inspection data + + ## Status implemented @@ -71,7 +73,7 @@ To pivot objects excluded from Cluster API chain to a target cluster, one can se `clusterctl.cluster.x-k8s.io=""` label on HardwareData and BareMetalHost CRDs. Current status annotation based pivoting workflow will stay as it is. However, CAPM3 machine controller will no longer copy `status.hardware` of BareMetalHost -to the annotation. Because that part will be avialable in the form of HardwareData CR +to the annotation. Because that part will be available in the form of HardwareData CR in the target cluster. ### Implementation Details/Notes/Constraints @@ -185,7 +187,7 @@ documented. - Add HardwareData API - Modify the operator code -- Adjust CAPM3 machine controller to exlude writing `status.hardware` into the statusAnnotation +- Adjust CAPM3 machine controller to exclude writing `status.hardware` into the statusAnnotation - Add unit tests - Update documentation diff --git a/design/baremetal-operator/host-config-drive.md b/design/baremetal-operator/host-config-drive.md index bfefdaac..24e1c97e 100644 --- a/design/baremetal-operator/host-config-drive.md +++ b/design/baremetal-operator/host-config-drive.md @@ -7,6 +7,8 @@ # host-config-drive + + ## Status [Implemented](https://github.com/metal3-io/baremetal-operator/pull/70) diff --git a/design/baremetal-operator/how-ironic-works.md b/design/baremetal-operator/how-ironic-works.md index d4819c81..5c224d19 100644 --- a/design/baremetal-operator/how-ironic-works.md +++ b/design/baremetal-operator/how-ironic-works.md @@ -7,8 +7,10 @@ # how-ironic-works + + This document explains how to use ironic in order to achieve various -tasks such as creating a node, recreating a node, unprovisioning a +tasks such as creating a node, recreating a node, deprovisioning a node, and deleting a node. This is not intended to be design specific documentation, but intends @@ -29,7 +31,7 @@ network attached power distribution unit. Typically nodes are booted utilizing PXE. In the most ideal scenario this would be a hybrid PXE/iPXE configuration such that the deployment ramdisk -for ironic is able to be quickly and efficently transferred to the +for ironic is able to be quickly and efficiently transferred to the node. In order to assert this configuration at boot time, a dedicated DHCP server @@ -70,13 +72,13 @@ The basic workflow consists of: inventory. 4. Ironic initiates deployment by first identifying the root disk upon which the disk image is to be written. By default this will be the - smallest storage device available, and can be overridden via explict + smallest storage device available, and can be overridden via explicit configuration of a [root_device hint](https://docs.openstack.org/ironic/latest/install/advanced.html#specifying-the-disk-for-deployment-root-device-hints) 5. The deployment ramdisk downloads the image to be written and streams that to the storage device. 6. If defined as part of the deployment, ironic will add an additional partition for a configuration drive. Ironic will then write the - configuraiton drive to disk + configuration drive to disk 7. Finally ironic reboots the machine. There are some additional steps that ironic performs, mainly fixing @@ -273,7 +275,7 @@ Further information can be found in ironic's Inspection may be used if a baremetal node has not been already discovered or inspected previously in order to collect up to date details about the -hardware. This is particullarly important in order to update the records +hardware. This is particularly important in order to update the records of networking ports for identification of the baremetal node and creation of PXE/iPXE configuration files in order to help ensure that baremetal node is quickly booted for booting into the deployment and discovery ramdisk. @@ -284,12 +286,12 @@ is quickly booted for booting into the deployment and discovery ramdisk. ``` This operation can only be performed in the "manageable" ironic node state. -If the node is already in the "available" state, the same requst can be used +If the node is already in the "available" state, the same request can be used with a target of "manage", and then the target of "inspect" can be utilized to step through the state machine. After inspection, it is advisable to return nodes to an "available" state. -This can be performed simillarly via the target "provide". +This can be performed similarly via the target "provide". ### How to deploy @@ -315,7 +317,7 @@ Starting with the bare metal node in the "available" provision_state: This configuration does two things. First sets the image and checksum to be utilized for image verification, and sets an "instance_uuid" value which acts as a signal to any client that the node has been claimed by - an API cient. The instance_uuid can be set to any value, and is + an API client. The instance_uuid can be set to any value, and is ultimately not required. 2. Request ironic to perform a "validate" operation on the information @@ -394,14 +396,14 @@ Starting with the bare metal node in the "available" provision_state: A "deploy failed" state indicates that the deployment failed, and additional details as to why can be retrieved from the "last_error" fiend in the JSON document. With newer versions of ironic, greater - granularity can be observed by also refering the "deploy_step" + granularity can be observed by also referring the "deploy_step" field, however this is a relatively new feature in ironic and the information provided is fairly broad as of the time this document was written. -### How to unprovision a baremetal node +### How to deprovision a baremetal node -A provisioned, or "active" baremetal node can be unprovisioned by sending +A provisioned, or "active" baremetal node can be deprovisioned by sending a state change request to the ironic api. This request will move the baremetal node through the "cleaning" process which ironic utilizes to erase the contents of the disks. This can be a time intensive process, diff --git a/design/baremetal-operator/image-builder-integration.md b/design/baremetal-operator/image-builder-integration.md index d5182925..b0975ebb 100644 --- a/design/baremetal-operator/image-builder-integration.md +++ b/design/baremetal-operator/image-builder-integration.md @@ -7,6 +7,8 @@ # Custom agent image controller + + ## Status implemented @@ -17,7 +19,7 @@ Enable a custom image containing the ironic-python-agent to be built for each BareMetalHost, instead of requiring all hosts to use the same agent image. The interface to the image builder will be defined by a new PreprovisioningImage CR in metal³, with users able to substitute their own implementations of image -building (in most cases this is expected to involve light customisation of an +building (in most cases this is expected to involve light customization of an existing image) by creating a controller. The baremetal-operator will create and use PreprovisioningImages as required when configured to do so. @@ -41,7 +43,7 @@ image. ### Goals -- Allow each host to use its own deploy ramdisk image customised with an +- Allow each host to use its own deploy ramdisk image customized with an appropriate network configuration. ### Non-Goals @@ -81,7 +83,7 @@ The Status will contain the following fields: A default controller for this resource type will be implemented that simply sets a fixed URL (supplied in its own environment or command line) as the output. However, provision will be made for interested parties to implement -alternate controllers to allow image customisation by making it easy to disable +alternate controllers to allow image customization by making it easy to disable this default controller. A command-line switch (defaulting to off) will enable integration between the @@ -122,11 +124,11 @@ Deprovisioning states, or when required by Ironic. The contents of the networkData Secret are generally assumed to be in the same format output by OpenStack and consumable by cloud-init. However, for Metal³'s purposes this is not a requirement as the data is passed through directly. -Authors of image customisation controllers are free to interpret the data in +Authors of image customization controllers are free to interpret the data in any way they see fit. Since PXE-booted hosts generally must be connected to the provisioning network -on an untagged VLAN using LACP for any NIC bonding, and on the provisioning +on an untagged VLAN using `LACP` for any NIC bonding, and on the provisioning network ironic will supply an IP address via DHCP, there should be no need for this feature other than when using virtualmedia drivers. An API option can always be added later if this proves not to be the case. @@ -216,13 +218,13 @@ now baked in to the API. Overall this is more flexible, since the image URL can be added in any way (not necessarily by adding a separate controller). It also has fewer moving parts. On the other hand, the more opinionated proposal above provides a more -stuctured way for associating the network data with the BareMetalHost it +structured way for associating the network data with the BareMetalHost it applies to. -### Have Ironic customise the image +### Have Ironic customize the image Currently Ironic just boots the Node with a given kernel and initrd. However, -when deploying using virtual media it has the capability to [customise the ISO +when deploying using virtual media it has the capability to [customize the ISO image to include the networkData](https://docs.openstack.org/ironic/latest/admin/dhcp-less.html#configuring-network-data). (Specifically, this is implemented in the iLO and redfish drivers, and @@ -242,7 +244,7 @@ ramdisk for discovery). Ironic verifies the data against a JSON Schema, whereas currently the networkData field in the BareMetalHost is free-form JSON. However, the choice -of schema is customisable by a config option, so it could be set to free-form +of schema is customizable by a config option, so it could be set to free-form to avoid breaking backward compatibility for existing resources. With this strategy we would always have to update the network data when it @@ -251,19 +253,19 @@ administrator or other user. ### Configure the IP address from within a fixed image -Using IPv6 Neighbour Discovery, we can determine the network prefix for each +Using IPv6 Neighbor Discovery, we can determine the network prefix for each interface. Using the network prefix we can statelessly choose a static IP -address without fear of collison (by using the Modified EUI-64 method based on +address without fear of collision (by using the Modified EUI-64 method based on the MAC address, and/or a stable privacy address). -If the host is not directly attached to the network Ironic is on, Neighbour +If the host is not directly attached to the network Ironic is on, Neighbor Discovery can also locate routers on the attached networks and identify which are suitable to be used as a default route. -For dynamically configured bonds (i.e. using LACP), only one port in the bond +For dynamically configured bonds (i.e. using `LACP`), only one port in the bond will be up, but this should be sufficient for the purposes of the ramdisk. -Information about VLANs and static bonds can be obtained only from LLDP. This +Information about VLANs and static bonds can be obtained only from `LLDP`. This information could be theoretically be used to automatically configure the interfaces on the ramdisk. However, this is dependent on the network switch configuration, and users may prefer not to rely on that (although we also rely @@ -277,8 +279,8 @@ environments. ## References -- [Proposal for customisable deployment +- [Proposal for customizable deployment procedure](https://github.com/metal3-io/metal3-docs/pull/180) that includes the alternate option of specifying the deploy image in the BareMetalHost Spec. - [Stateless IPv6 address - autoconfiguration](https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration) + auto configuration](https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration) diff --git a/design/baremetal-operator/inspection-api.md b/design/baremetal-operator/inspection-api.md index dc3fd14a..e42704fc 100644 --- a/design/baremetal-operator/inspection-api.md +++ b/design/baremetal-operator/inspection-api.md @@ -79,7 +79,7 @@ more formal interface for future Metal³ remediation controller. ## Alternatives One alternative approach to keep hardware details updated is to run Ironic -Python Agent (IPA) as a pod on the node which would be contstantly updating the +Python Agent (IPA) as a pod on the node which would be constantly updating the hardware details of the host. ## References diff --git a/design/baremetal-operator/kubebuilder-migration.md b/design/baremetal-operator/kubebuilder-migration.md index 65e4dc29..9a9bd663 100644 --- a/design/baremetal-operator/kubebuilder-migration.md +++ b/design/baremetal-operator/kubebuilder-migration.md @@ -1,5 +1,7 @@ # kubebuilder-migration + + ## Status implemented diff --git a/design/baremetal-operator/managing-provisioning-dependencies.md b/design/baremetal-operator/managing-provisioning-dependencies.md index ba73880a..4794882e 100644 --- a/design/baremetal-operator/managing-provisioning-dependencies.md +++ b/design/baremetal-operator/managing-provisioning-dependencies.md @@ -7,6 +7,8 @@ # managing-provisioning-dependencies + + ## Status in-progress diff --git a/design/baremetal-operator/raid-disk-controller.md b/design/baremetal-operator/raid-disk-controller.md index 35c5eae2..158ff401 100644 --- a/design/baremetal-operator/raid-disk-controller.md +++ b/design/baremetal-operator/raid-disk-controller.md @@ -130,7 +130,7 @@ there. ### Risks and Mitigations Since we will be specifying physical disks to be used, care needs to be taken -to not accidently erase media with sensitive data on them. It is very easy to +to not accidentally erase media with sensitive data on them. It is very easy to undesirably remove data from disks. ### Work Items diff --git a/design/baremetal-operator/reboot-interface.md b/design/baremetal-operator/reboot-interface.md index ac755f52..54d5837e 100644 --- a/design/baremetal-operator/reboot-interface.md +++ b/design/baremetal-operator/reboot-interface.md @@ -7,6 +7,8 @@ # reboot-interface + + ## Status implemented @@ -75,7 +77,7 @@ A new date-time field, ``pendingRebootSince``, will be added to the ``provisioning`` section of the BareMetalHost status. This records a time before which the Host was last requested to reboot (because we cannot trust any value from the user, who even if well intentioned, may have created the -timestamp on a machine that was not synchronised with the cluster or has a +timestamp on a machine that was not synchronized with the cluster or has a different timezone). Since the user interface requirements are still unclear, we will follow @@ -200,5 +202,5 @@ noticed them. Selecting this option would also make it more difficult to add further reboot-related API features in the future. The request could be made by adding to a list of client-chosen strings in the -Host spec. This effectively formalises the annotation-based system proposed +Host spec. This effectively formalizes the annotation-based system proposed here and makes it a permanent part of the interface. diff --git a/design/baremetal-operator/remove-host.md b/design/baremetal-operator/remove-host.md index 930840ff..600d8276 100644 --- a/design/baremetal-operator/remove-host.md +++ b/design/baremetal-operator/remove-host.md @@ -43,7 +43,7 @@ another Machine without a host could claim it before it gets deleted. Additionally, by deleting the Machine before scaling down the MachineSet, the MachineSet will try to replace it with a new Machine resource. That new -resourse could match a BareMetalHost if one is available and cause it to start +resource could match a BareMetalHost if one is available and cause it to start provisioning. For this reason, it is better to not directly delete a Machine. ### Scale down the MachineSet diff --git a/design/baremetal-operator/uefi-http-boot.md b/design/baremetal-operator/uefi-http-boot.md index 41a54686..7e0460d6 100644 --- a/design/baremetal-operator/uefi-http-boot.md +++ b/design/baremetal-operator/uefi-http-boot.md @@ -48,7 +48,7 @@ The new hardware driver supports UEFI HTTP boot using the ironic ## Design Details Using exclusively Redfish API, the accepted value of `Firmware Interface` and -`RAIDInterface` for the `redfish-uefihttp` hardware driver will be `redfish`. +`RAIDInterface` for the `redfish-uefihttp` hardware driver will be `redfish`. Secure Boot will also be supported. When the `redfish-uefihttp` hardware driver is used we need to configure the @@ -58,13 +58,13 @@ in ironic-image. ### Implementation Details/Notes/Constraints It should be enough to add the new `redfish-uefihttp` hardware driver to -BMO to support the UEFI HTTP boot feature. +BMO to support the UEFI HTTP boot feature. As for the `redfish-virtualmedia` driver, the new `redfish-uefihttp` relies on network boot from an ISO image that is composed by Ironic, but unlike -Virtual Media boot, it requires a Provisioning Network to be configured. +Virtual Media boot, it requires a Provisioning Network to be configured. This is because the UEFI HTTP boot is essentially "secured PXE" designed to overcome limitations of the traditional PXE boot method, and it requires -functional DNS, DHCP and HTTP servers to be configured. +functional DNS, DHCP and HTTP servers to be configured. The ISO image is provided by the HTTP server and the host boots from it exactly like it used to boot from a standard ramdisk during PXE booting. @@ -88,8 +88,8 @@ already completed](https://review.opendev.org/c/openstack/ironic/+/900964). ### Test Plan -The new hardwre driver can currently be tested only on supported hardware -as the Redfish support must be enabled and supported by the BMC. +The new hardware driver can currently be tested only on supported hardware +as the Redfish support must be enabled and supported by the BMC. Although the support for UEFI HTTP boot has been added to sushy-tools, so the current BMO e2e tests set can be expanded to cover this scenario. @@ -109,7 +109,7 @@ None Adding one more hardware driver with a different boot interface complicates the decision process to decide which boot interface to use, in particular in this case between `redfish-virtualmedia` and `redfish-uefihttp` since they both -rely on network booting from an ISO image. +rely on network booting from an ISO image. In general, the main difference is that the UEFI HTTP boot supports Secure Boot, while virtual media does not, but on the other hand, the UEFI HTTP boot requires a DHCP server to be present on the network in order to handle @@ -118,7 +118,7 @@ the boot media discovery and IP address management. ## Alternatives The users will keep using other hardware drivers already implemented in -Baremetal Operator API. +Baremetal Operator API. The existing interfaces do not cover some important cases and have some limitations, such as: @@ -128,5 +128,5 @@ Control Plane from the BMC. ## References -[UEFI 2.5 release notes](https://uefi.org/sites/default/files/resources/UEFI%202_5.pdf) +[UEFI 2.5 release notes](https://uefi.org/sites/default/files/resources/UEFI%202_5.pdf) [Ironic HTTP Boot](https://docs.openstack.org/ironic/latest/admin/interfaces/boot.html#http-boot) diff --git a/design/baremetal-operator/user-defined-root-device-hints.md b/design/baremetal-operator/user-defined-root-device-hints.md index 9a00d882..ef74090d 100644 --- a/design/baremetal-operator/user-defined-root-device-hints.md +++ b/design/baremetal-operator/user-defined-root-device-hints.md @@ -13,7 +13,7 @@ implemented ## Summary -This document explains how rootdevicehints could be given as user +This document explains how `rootdevicehints` could be given as user defined parameters as part BaremetalHostSpec. The idea is that user would have the possibility to define selective constraints for root device selection. Sometimes selective constrains will not be @@ -154,7 +154,7 @@ This requires refactoring of BMO repository code. ### Upgrade / Downgrade Strategy In the original inventory code there is an Storage struct that has -pretty much the same content, but by having a separete struct we can +pretty much the same content, but by having a separate struct we can control easily if we want to add or deprecate support for some hints. ### Version Skew Strategy diff --git a/design/cluster-api-provider-metal3/allow_disabling_node_disk_cleaning.md b/design/cluster-api-provider-metal3/allow_disabling_node_disk_cleaning.md index 4caa2c9e..4379c3e4 100644 --- a/design/cluster-api-provider-metal3/allow_disabling_node_disk_cleaning.md +++ b/design/cluster-api-provider-metal3/allow_disabling_node_disk_cleaning.md @@ -7,6 +7,8 @@ http://creativecommons.org/licenses/by/3.0/legalcode # allow disabling automated cleaning + + ## Status implemented @@ -144,7 +146,7 @@ spec: 3. Metal3MachineTemplate controller keeps reconciling the Metal3MachineTemplate objects. Once the update is seen on the Metal3MachineTemplate, Metal3MachineTemplate controller - starts mapping all the Metal3Machines referenced by that particular Metla3MachineTemplate, + starts mapping all the Metal3Machines referenced by that particular Metal3MachineTemplate, and updates the `automatedCleaningMode` field to Disabled on all the referenced Metal3Machines. @@ -221,7 +223,7 @@ the conductor in [ironic.conf](https://github.com/metal3-io/ironic-image/blob/16 and then enabled on the node level for nodes that require disk cleaning. However, this option introduces a couple of issues: -1. As mentioned by @dtanstur in [2008113](https://storyboard.openstack.org/#!/story/2008113) +1. As mentioned by @dtantsur in [2008113](https://storyboard.openstack.org/#!/story/2008113) there could be some security concerns if we disable automated cleaning globally. 2. Upgrade operations do not happen as frequently as provisioning & de-provisioning. diff --git a/design/cluster-api-provider-metal3/capm3-remediation-controller-proposal.md b/design/cluster-api-provider-metal3/capm3-remediation-controller-proposal.md index 0f149b77..96be8826 100644 --- a/design/cluster-api-provider-metal3/capm3-remediation-controller-proposal.md +++ b/design/cluster-api-provider-metal3/capm3-remediation-controller-proposal.md @@ -7,6 +7,8 @@ # capm3-remediation-controller + + Co-authored-by: @jan-est, @beekhof, @n1r1, @maelk, @fmuyassarov. ## Status diff --git a/design/cluster-api-provider-metal3/node_reuse.md b/design/cluster-api-provider-metal3/node_reuse.md index e1c24101..9873f077 100644 --- a/design/cluster-api-provider-metal3/node_reuse.md +++ b/design/cluster-api-provider-metal3/node_reuse.md @@ -190,7 +190,7 @@ Step2 can be done as follows: diagram above, CAPM3 machine controller always picks labelled hosts (when found) regardless of nodeReuse feature is disabled/enabled. The reason is, we want to ensure that the controller doesn't miss labelled hosts. In short, - labelled hosts always take the presedence over unlabelled hosts during selection. + labelled hosts always take the precedence over unlabelled hosts during selection. ### Risks and Mitigations diff --git a/design/community/book-proposal.md b/design/community/book-proposal.md index f12f626c..343e0ca6 100644 --- a/design/community/book-proposal.md +++ b/design/community/book-proposal.md @@ -7,6 +7,8 @@ http://creativecommons.org/licenses/by/3.0/legalcode # metal³ user-guide + + ## Status implementable diff --git a/design/community/foundation-proposal.md b/design/community/foundation-proposal.md index 00e52bad..571f6fe1 100644 --- a/design/community/foundation-proposal.md +++ b/design/community/foundation-proposal.md @@ -7,6 +7,8 @@ # Community Future - Proposal to Move to the CNCF Sandbox + + ## Status provisional diff --git a/design/hardware-classification-controller/expected-hardware-configuration-validation.md b/design/hardware-classification-controller/expected-hardware-configuration-validation.md index fcc30629..86786682 100644 --- a/design/hardware-classification-controller/expected-hardware-configuration-validation.md +++ b/design/hardware-classification-controller/expected-hardware-configuration-validation.md @@ -85,7 +85,7 @@ bare-metal](https://github.com/metal3-io/baremetal-operator/blob/93cd6bdae72ff44 - Create a classification_manager.go file. Create a function which will call appropriate filter written in classification_filter.go - based on minimum or maximum requiremnets specified by user in + based on minimum or maximum requirements specified by user in CRD_yaml. - The ClassificationFilters.go file will contain implementation of diff --git a/design/hardware-classification-controller/support-for-error-count-parameter-hwcc.md b/design/hardware-classification-controller/support-for-error-count-parameter-hwcc.md index 9487c222..7951e095 100644 --- a/design/hardware-classification-controller/support-for-error-count-parameter-hwcc.md +++ b/design/hardware-classification-controller/support-for-error-count-parameter-hwcc.md @@ -1,5 +1,7 @@ # add support for matched, unmatched and error hosts count parameter + + ## Status Implementable @@ -50,7 +52,7 @@ HWCC only supports error state which are defined in Baremetal host. ## Proposal - In HWCC Status, introduce new fields to show the count of - matched, unmatched and failedhost. + `matched`, `unmatched` and `failedhost`. - In addition to get the count of host failed due to specific failure. diff --git a/design/hardware-classification-controller/support-for-new-parameters-hwcc-DiskAndNIC.md b/design/hardware-classification-controller/support-for-new-parameters-hwcc-DiskAndNIC.md index 68cfbdca..f516b42a 100644 --- a/design/hardware-classification-controller/support-for-new-parameters-hwcc-DiskAndNIC.md +++ b/design/hardware-classification-controller/support-for-new-parameters-hwcc-DiskAndNIC.md @@ -59,7 +59,7 @@ Add support for new parameters: For selection of NVMe disk, user can provide `rotational` parameter as false and `hctl` parameter should be blank. - For example: For HDD disk, user can provide `hctl`value as "0:0:N:0" + For example: For HDD disk, user can provide `hctl` value as "0:0:N:0" and `rotational` flag as "True". YAML rules for single Disk: diff --git a/design/helm-charts/single-pod-helm-chart.md b/design/helm-charts/single-pod-helm-chart.md index 052c87d8..7b7a696f 100644 --- a/design/helm-charts/single-pod-helm-chart.md +++ b/design/helm-charts/single-pod-helm-chart.md @@ -24,7 +24,7 @@ The goal is to support a popular way to deploy Kubernetes applications to simplify creation of development environments on top of arbitrary Kubernetes clusters. -Another goal to preare to set a standard for production-grade deployment +Another goal to prepare to set a standard for production-grade deployment of Metal3 and its components. ### Non-Goals @@ -113,7 +113,7 @@ creation experience. ## Alternatives -Currently, the deloyment functionality is already implemented as +Currently, the deployment functionality is already implemented as ``metal3-dev-env`` scripts. Another alternative is to use plain Kubernetes manifest from ```baremetal-operator/deploy`` for deployment on K8s. diff --git a/design/ip-address-manager/ip-address-management-for-networkdata.md b/design/ip-address-manager/ip-address-management-for-networkdata.md index 1b4de5ef..1f9e8b37 100644 --- a/design/ip-address-manager/ip-address-management-for-networkdata.md +++ b/design/ip-address-manager/ip-address-management-for-networkdata.md @@ -135,7 +135,7 @@ cluster to prevent future conflicts. ### Implementation Details/Notes/Constraints - This proposal should be fully backwards compatible and not modify any existing - behaviour. + behavior. - When shared among multiple machine deployment, the allocation would be random as much as possible to avoid conflicts and re-use as much as possible. - If not needed, this feature should not require the user to modify anything @@ -401,7 +401,7 @@ of the *IPAddress* objects. ### Upgrade / Downgrade Strategy -No change would be required to keep the existing behaviour (the ipaddress field +No change would be required to keep the existing behavior (the ipaddress field could be removed, but was never part of a released API). In order to start using this feature, one will just need to modify the *Template* and create *IPPool* objects. diff --git a/docs/presentations/README.md b/docs/presentations/README.md index 6b2b3b10..e4a8dc21 100644 --- a/docs/presentations/README.md +++ b/docs/presentations/README.md @@ -1,5 +1,7 @@ # Metal3 Presentations + + ## Goal The motivation behind this initiative is to provide easy to use presentation @@ -10,7 +12,7 @@ spread the project by helping presenters save time and focus on their content. ## Framework -We are using the [Revealjs](https://revealjs.com/) framework to create the +We are using the [RevealJS](https://revealjs.com/) framework to create the presentation. To contribute a presentation please create a directory, at the `meta3-docs/docs/presentations` path, with your files associated with the presentation, for example :- @@ -56,7 +58,7 @@ For exporting the presentation in pdf format, you can use decktape reveal test-presentation.html test_deck.pdf ``` -Exporing to .odp or .pptx formats is not supported but +Exporting to .odp or .pptx formats is not supported but this [issue](https://github.com/hakimel/reveal.js/issues/1702) might help. ## Example diff --git a/docs/user-guide/src/baremetal/guide.md b/docs/user-guide/src/baremetal/guide.md index 24afa91b..9aff0b11 100644 --- a/docs/user-guide/src/baremetal/guide.md +++ b/docs/user-guide/src/baremetal/guide.md @@ -27,7 +27,7 @@ See [Install Ironic](../ironic/ironic_installation.md) for other requirements. allows them to communicate with each other and connect to internet. ```bash - # Create a veth iterface peer. + # Create a veth interface peer. sudo ip link add ironicendpoint type veth peer name ironic-peer # Create provisioning bridge. @@ -54,10 +54,10 @@ See [Install Ironic](../ironic/ironic_installation.md) for other requirements. # Set VLAN interface to be up ip link set up dev bmext - # Check if bmext interface is addded to the bridge + # Check if bmext interface is added to the bridge brctl show baremetal | grep bmext - # Add bmext to baremeatal bridge + # Add bmext to baremetal bridge brctl addif baremetal bmext ``` @@ -79,7 +79,7 @@ See [Install Ironic](../ironic/ironic_installation.md) for other requirements. ```bash # Change IMAGE_NAME and IMAGE_RAW_NAME according to what you download from artifactory - cd /opt/metal3-dev-env/ironic/hrtml/images + cd /opt/metal3-dev-env/ironic/html/images IMAGE_NAME="CENTOS_9_NODE_IMAGE_K8S_v1.27.1.qcow2" IMAGE_RAW_NAME="CENTOS_9_NODE_IMAGE_K8S_v1.27.1-raw.img" qemu-img convert -O raw "${IMAGE_NAME}" "${IMAGE_RAW_NAME}" @@ -108,7 +108,7 @@ See [Install Ironic](../ironic/ironic_installation.md) for other requirements. kubectl create namespace metal3 clusterctl init --core cluster-api --bootstrap kubeadm --control-plane kubeadm --infrastructure metal3 # NOTE: In clusterctl init you can change the version of provider like this 'cluster-api{{#releasetag owner:"kubernetes-sigs" repo:"cluster-api"}}', - # if no version is given by deafult latest stable release will be used. + # if no version is given by default latest stable release will be used. ``` ## Install provisioning components @@ -204,15 +204,15 @@ See [Install Ironic](../ironic/ironic_installation.md) for other requirements. The next step is to create a workload cluster from these BareMetalHosts. -## Create and apply cluster, controlplane and worker template +## Create and apply cluster, control plane and worker template ```bash #API endpoint IP and port for target cluster export CLUSTER_APIENDPOINT_HOST="192.168.111.249" export CLUSTER_APIENDPOINT_PORT="6443" - # Export node image variable and node image hash varibale that we created before. - # Change name according to what was downlowded from artifactory + # Export node image variable and node image hash variable that we created before. + # Change name according to what was downloaded from artifactory export IMAGE_URL=http://172.22.0.1/images/CENTOS_9_NODE_IMAGE_K8S_v1.27.1-raw.img export IMAGE_CHECKSUM=http://172.22.0.1/images/CENTOS_9_NODE_IMAGE_K8S_v1.27.1-raw.img.sha256sum export IMAGE_CHECKSUM_TYPE=sha256 diff --git a/docs/user-guide/src/bmo/firmware_settings.md b/docs/user-guide/src/bmo/firmware_settings.md index 45df4418..d636a5bd 100644 --- a/docs/user-guide/src/bmo/firmware_settings.md +++ b/docs/user-guide/src/bmo/firmware_settings.md @@ -1,5 +1,7 @@ # Firmware Settings + + Metal3 supports modifying firmware settings of the hosts before provisioning them. This feature can be used, for example, to enable or disable CPU virtualization extensions, huge pages or SRIOV support. The corresponding diff --git a/docs/user-guide/src/bmo/install_baremetal_operator.md b/docs/user-guide/src/bmo/install_baremetal_operator.md index 3527ac8e..2ba13518 100644 --- a/docs/user-guide/src/bmo/install_baremetal_operator.md +++ b/docs/user-guide/src/bmo/install_baremetal_operator.md @@ -1,5 +1,7 @@ # Install Baremetal Operator + + Installing Baremetal Operator (BMO) involves usually three steps: 1. Clone Metal3 BMO repository `https://github.com/metal3-io/baremetal-operator.git`. @@ -213,7 +215,7 @@ config/ The `config` directory has one top level folder for deployment, namely `default` and it deploys only baremetal-operator through kustomization file calling `manager` folder. In addition, `basic-auth`, `certmanager`, `crd`, `namespace`, -`prometheus`, `rbac`, `tls` and `webhook`folders have their own kustomization +`prometheus`, `rbac`, `tls` and `webhook` folders have their own kustomization and yaml files. `samples` folder includes yaml representation of sample CRDs. ### Current structure of ironic-deployment directory diff --git a/docs/user-guide/src/bmo/instance_customization.md b/docs/user-guide/src/bmo/instance_customization.md index c9e3b8b6..f67393f9 100644 --- a/docs/user-guide/src/bmo/instance_customization.md +++ b/docs/user-guide/src/bmo/instance_customization.md @@ -1,5 +1,7 @@ # Instance Customization + + When provisioning bare-metal machines, it is usually required to customize the resulting instances. Common use cases include injecting SSH keys, adding users, installing software, starting services or configuring networking. diff --git a/docs/user-guide/src/bmo/introduction.md b/docs/user-guide/src/bmo/introduction.md index 1bef8cc8..39965a0a 100644 --- a/docs/user-guide/src/bmo/introduction.md +++ b/docs/user-guide/src/bmo/introduction.md @@ -68,7 +68,7 @@ To provision a bare-metal machine, you will need a few more properties: [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html), some distributions use [ignition](https://coreos.github.io/ignition/). 3. Optionally, network data: a secret with the network configuration that is - enterpreted by the first-boot service. In some cases, the network data is + interpreted by the first-boot service. In some cases, the network data is embedded in the user data instead. Here is a complete example of a host that will be provisioned with a CentOS 9 diff --git a/docs/user-guide/src/bmo/provisioning.md b/docs/user-guide/src/bmo/provisioning.md index cf137366..8bd225aa 100644 --- a/docs/user-guide/src/bmo/provisioning.md +++ b/docs/user-guide/src/bmo/provisioning.md @@ -1,5 +1,7 @@ # Provisioning and Deprovisioning + + The most fundamental feature of Metal3 Bare Metal Operator is provisioning of bare-metal machines with a user-provided image. This document explains how to provision machines using the `BareMetalHost` API directly. Users of the Cluster diff --git a/docs/user-guide/src/bmo/raid.md b/docs/user-guide/src/bmo/raid.md index 56053cd8..9566ddc9 100644 --- a/docs/user-guide/src/bmo/raid.md +++ b/docs/user-guide/src/bmo/raid.md @@ -156,7 +156,7 @@ spec: - level: "1" physicalDisks: - serialNumber: abcd - - serialNumber: efgh + - serialNumber: fake ``` ### Removing software RAID diff --git a/docs/user-guide/src/bmo/root_device_hints.md b/docs/user-guide/src/bmo/root_device_hints.md index e4640ed5..e75e91f2 100644 --- a/docs/user-guide/src/bmo/root_device_hints.md +++ b/docs/user-guide/src/bmo/root_device_hints.md @@ -59,7 +59,7 @@ them. Available hints are: identifier with the vendor extension appended. - `wwnVendorExtension` -- A string containing the unique vendor - storage indentifier. + storage identifier. - `rotational` -- A boolean indicating whether the device must be a rotating disk (`true`) or not (`false`). Examples of non-rotational devices @@ -106,7 +106,7 @@ implies using `/dev/sda` as the root device. In a future version of BareMetalHost API, the hardware profile concept will be disabled, and Metal3 will default to having no root device hints by default. In this case, the default logic in Ironic will apply: the smaller block device -that is at least 4 GiB. If you want this logic to apply in the current verson +that is at least 4 GiB. If you want this logic to apply in the current version of the API, use the `empty` profile: ```yaml diff --git a/docs/user-guide/src/bmo/state_machine.md b/docs/user-guide/src/bmo/state_machine.md index 971e360c..29384dc0 100644 --- a/docs/user-guide/src/bmo/state_machine.md +++ b/docs/user-guide/src/bmo/state_machine.md @@ -52,7 +52,7 @@ status: - `OK` -- the host is healthy and operational. - `discovered` -- the host is known to Metal3 but lacks the required information for the normal operation (usually, the BMC credentials). -- `error` -- error has occured, see the `status.errorType` and +- `error` -- error has occurred, see the `status.errorType` and `status.errorMessage` fields for details. - `delayed` -- cannot proceed with the provisioning because the maximum number of the hosts in the given state has been reached. diff --git a/docs/user-guide/src/capm3/automated_cleaning.md b/docs/user-guide/src/capm3/automated_cleaning.md index 747edb97..5f405962 100644 --- a/docs/user-guide/src/capm3/automated_cleaning.md +++ b/docs/user-guide/src/capm3/automated_cleaning.md @@ -1,5 +1,7 @@ # Automated Cleaning + + Before reading this page, please see [Baremetal Operator Automated Cleaning](../bmo/automated_cleaning.md) page. If you are using only Metal3 Baremetal Operator, you can skip this page and refer to Baremetal diff --git a/docs/user-guide/src/capm3/clusterclass.md b/docs/user-guide/src/capm3/clusterclass.md index 95ed47df..0f2e2d2d 100644 --- a/docs/user-guide/src/capm3/clusterclass.md +++ b/docs/user-guide/src/capm3/clusterclass.md @@ -27,7 +27,7 @@ controller to instantiate the cluster. for the instantiated cluster. - Metal3MachineTemplate - templates that will be used to create Metal3Machine -objects. Can be defined saparately for control plane and worker nodes. +objects. Can be defined separately for control plane and worker nodes. - KubeadmConfigTemplate - a template for Kubeadm config. diff --git a/docs/user-guide/src/capm3/installation_guide.md b/docs/user-guide/src/capm3/installation_guide.md index 06b76291..bfb6032d 100644 --- a/docs/user-guide/src/capm3/installation_guide.md +++ b/docs/user-guide/src/capm3/installation_guide.md @@ -13,7 +13,7 @@ install them yourself. 1. Install `kustomize`, refer to official instructions [here](https://kubectl.docs.kubernetes.io/installation/kustomize/). 1. Install Ironic, refer to [this page](../ironic/ironic_installation.html). 1. Install Baremetal Operator, refer to [this page](../bmo/install_baremetal_operator.html). -1. Install Cluster API core compoenents i.e., core, bootstrap and control-plane providers. This will also install cert-manager, if it is not already installed. +1. Install Cluster API core components i.e., core, bootstrap and control-plane providers. This will also install cert-manager, if it is not already installed. ```bash clusterctl init --core cluster-api{{#releasetag owner:"kubernetes-sigs" repo:"cluster-api"}} --bootstrap kubeadm{{#releasetag owner:"kubernetes-sigs" repo:"cluster-api"}} \ diff --git a/docs/user-guide/src/capm3/label_sync.md b/docs/user-guide/src/capm3/label_sync.md index eb7b46fd..f7289e0e 100644 --- a/docs/user-guide/src/capm3/label_sync.md +++ b/docs/user-guide/src/capm3/label_sync.md @@ -9,10 +9,10 @@ To use label synchronization user needs to define prefix(es) for labels. Only labels that fall within prefix set are synchronized. User defines prefixes with annotation in Metal3Cluster object by using **metal3.io/metal3-label-sync-prefixes** annotation key and gives prefixes as -annotation value. Prefixes should be seperated by comma. +annotation value. Prefixes should be separated by comma. In the following example we are defining two label prefixes for label -syncronization: **test.foobar.io** and **my-prefix**. +synchronization: **test.foobar.io** and **my-prefix**. ```bash kubectl annotate metal3cluster test1 metal3.io/metal3-label-sync-prefixes=test.foobar.io,my-prefix -n=metal3 --overwrite @@ -28,7 +28,7 @@ kubectl label baremetalhosts node-0 my-prefix/rack=xyz-123 -n=metal3 kubectl label baremetalhosts node-0 test.foobar.io/group=abc -n=metal3 ``` -**Note:** Prefixes should be seperated from the rest of the label key by **"/"**, e.g. my-prefix/rack, test.foobar.io/xyz +**Note:** Prefixes should be separated from the rest of the label key by **"/"**, e.g. my-prefix/rack, test.foobar.io/xyz Now label sync controller will apply same labels to corresponding Kubernetes node. diff --git a/docs/user-guide/src/capm3/pivoting.md b/docs/user-guide/src/capm3/pivoting.md index 657e26a4..159fa4ef 100644 --- a/docs/user-guide/src/capm3/pivoting.md +++ b/docs/user-guide/src/capm3/pivoting.md @@ -1,5 +1,7 @@ # CAPM3 Pivoting + + ## What is pivoting Cluster API Provider Metal3 (CAPM3) implements support for CAPI's 'move/pivoting' feature. @@ -60,7 +62,7 @@ bootstrap cluster. If not, it has to be deployed before the `clusterctl init` and the BMH CRDs need to be labeled accordingly manually. Separate labeling for BMH CRDs is required because since CAPM3 release [v0.5.0](https://github.com/metal3-io/cluster-api-provider-metal3/releases/tag/v0.5.0) - BMO/BMH CRDs are not deplopyed as part of CAPM3 deployment anymore. + BMO/BMH CRDs are not deployed as part of CAPM3 deployment anymore. This is a prerequisite for both the management and the target cluster. 1. **Objects should have a proper owner reference chain.** diff --git a/docs/user-guide/src/developer_environment/tryit.md b/docs/user-guide/src/developer_environment/tryit.md index 11f7d030..d23041de 100644 --- a/docs/user-guide/src/developer_environment/tryit.md +++ b/docs/user-guide/src/developer_environment/tryit.md @@ -1,5 +1,7 @@ # Trying Metal3 on a development environment + + Ready to start taking steps towards your first experience with metal3? Follow these commands to get started! - [1. Environment Setup](#1-environment-setup) @@ -51,13 +53,13 @@ For execution with VMs - Manually **enable nested virtualization** if you don't have it enabled in your VM ```console - # To enable nested virtualization + # To enable nested virtualization # On Centos 9 streams (other distros may vary) # check the current setting - $ sudo cat /sys/module/kvm_intel/parameters/nested + $ sudo cat /sys/module/kvm_intel/parameters/nested N # disabled - $ sudo vi /etc/modprobe.d/kvm.conf + $ sudo vi /etc/modprobe.d/kvm.conf # uncomment either of the line # for Intel CPU, select [kvm_intel], for AMD CPU, select [kvm_amd] @@ -323,7 +325,7 @@ This section describes how to trigger the provisioning of a cluster and hosts vi `Machine` objects as part of the Cluster API integration. This uses Cluster API [v1beta1](https://github.com/kubernetes-sigs/cluster-api/tree/v1.0.2) and assumes that metal3-dev-env is deployed with the environment variable -**CAPM3_VERSION** set to **v1beta1**. This is the default behaviour. The v1beta1 deployment can be done with +**CAPM3_VERSION** set to **v1beta1**. This is the default behavior. The v1beta1 deployment can be done with Ubuntu 22.04 or Centos 9 Stream target host images. Please make sure to meet [resource requirements](#11-prerequisites) for successful deployment: diff --git a/docs/user-guide/src/introduction.md b/docs/user-guide/src/introduction.md index e0331aa8..6daf38be 100644 --- a/docs/user-guide/src/introduction.md +++ b/docs/user-guide/src/introduction.md @@ -6,6 +6,8 @@ # Metal³ + + The Metal³ project (pronounced: "Metal Kubed") provides components for bare metal host management with Kubernetes. You can enrol your bare metal machines, provision operating system images, and then, if you like, deploy Kubernetes diff --git a/docs/user-guide/src/ipam/ipam_installation.md b/docs/user-guide/src/ipam/ipam_installation.md index 6e6e89a7..b9f1aa90 100644 --- a/docs/user-guide/src/ipam/ipam_installation.md +++ b/docs/user-guide/src/ipam/ipam_installation.md @@ -4,7 +4,7 @@ This section will show how IPAM can be installed as a deployment in a cluster. ## Deploying controllers -CAPI and IPAM controllers need to be deployed at the begining. The IPAM controller has a dependency on Cluster API *Cluster* objects. CAPI CRDs and controllers must be deployed and the cluster objects should exist for successful deployments. +CAPI and IPAM controllers need to be deployed at the beginning. The IPAM controller has a dependency on Cluster API *Cluster* objects. CAPI CRDs and controllers must be deployed and the cluster objects should exist for successful deployments. ## Deployment diff --git a/docs/user-guide/src/ironic/introduction.md b/docs/user-guide/src/ironic/introduction.md index cb921e59..3dcb2f7d 100644 --- a/docs/user-guide/src/ironic/introduction.md +++ b/docs/user-guide/src/ironic/introduction.md @@ -30,13 +30,13 @@ behind native Kubernetes API. from bare metal machine registration and hardware specifications retrieval of newly discovered bare metal machines, configuration and provisioning with custom operating system images, up to machines reset, - cleaning for re-provisionionig or end-of-life retirement. + cleaning for re-provisioning or end-of-life retirement. ## How Metal3 uses Ironic [Bare Metal Operator](https://github.com/metal3-io/baremetal-operator) is the main component that interfaces with the Ironic API for all -operations needed to provision bare-metal hosts, such as hardware capabilites +operations needed to provision bare-metal hosts, such as hardware capabilities inspection, operating system installation, and re-initialization when restoring a bare-metal machine to its original status. diff --git a/docs/user-guide/src/ironic/ironic-container-images.md b/docs/user-guide/src/ironic/ironic-container-images.md index 037ab19a..05e00c22 100644 --- a/docs/user-guide/src/ironic/ironic-container-images.md +++ b/docs/user-guide/src/ironic/ironic-container-images.md @@ -1,5 +1,7 @@ # Ironic Container Images + + The currently available ironic container images are: | Name and link to repository | Published image | Content/Purpose | diff --git a/docs/user-guide/src/ironic/ironic_installation.md b/docs/user-guide/src/ironic/ironic_installation.md index 0efcff3d..a158e0eb 100644 --- a/docs/user-guide/src/ironic/ironic_installation.md +++ b/docs/user-guide/src/ironic/ironic_installation.md @@ -67,7 +67,7 @@ In the quickstart guide, we have demonstrated by creating an ironic kustomization overlay. While that is still what you should follow if you have specific requirements for your ironic deployment, we do provide an already-made overlay for the -most-common usecase, ironic with basic authentication and TLS. +most-common use case, ironic with basic authentication and TLS. We assume you are inside the local baremetal-operator path, if not you need to clone it first and `cd` to the root path. diff --git a/docs/user-guide/src/project-overview.md b/docs/user-guide/src/project-overview.md index d1ae76e6..10269fa6 100644 --- a/docs/user-guide/src/project-overview.md +++ b/docs/user-guide/src/project-overview.md @@ -38,7 +38,7 @@ machine. Ironic can then communicate with the IPA to perform the requested operation. The BareMetal Operator (BMO) is a Kubernetes controller that exposes parts of -Ironics capabilities through the Kubernetes API. This is essentially done +Ironic's capabilities through the Kubernetes API. This is essentially done through the BareMetalHost custom resource. The Cluster API infrastructure provider for Metal3 (CAPM3) provides the diff --git a/docs/user-guide/src/quick-start.md b/docs/user-guide/src/quick-start.md index 9d555da3..4c0c9575 100644 --- a/docs/user-guide/src/quick-start.md +++ b/docs/user-guide/src/quick-start.md @@ -1,5 +1,7 @@ # Quick-start for Metal3 + + This guide has been tested on Ubuntu server 22.04. It should be seen as an example rather than the absolute truth about how to deploy and use Metal3. We will cover two environments and two scenarios. The environments are diff --git a/docs/user-guide/src/security_policy.md b/docs/user-guide/src/security_policy.md index cf7e0232..30abd3e9 100644 --- a/docs/user-guide/src/security_policy.md +++ b/docs/user-guide/src/security_policy.md @@ -1,5 +1,7 @@ # Metal3-io security policy + + This document explains the general security policy for the whole [project](https://github.com/metal3-io) thus it is applicable for all of its active repositories and this file has to be referenced in each repository in diff --git a/docs/user-guide/src/version_support.md b/docs/user-guide/src/version_support.md index 259f5f3f..a2f38b79 100644 --- a/docs/user-guide/src/version_support.md +++ b/docs/user-guide/src/version_support.md @@ -39,13 +39,13 @@ IP Address Manager | v1.2 | v1beta1 | EOL | | v1.1 | v1beta1 | EOL | -The compatability of IPAM and CAPM3 API versions with CAPI is discussed +The compatibility of IPAM and CAPM3 API versions with CAPI is discussed [here](https://github.com/metal3-io/ip-address-manager#compatibility-with-cluster-api). ## Baremetal Operator Since `capm3-v1.1.2`, BMO follows the semantic versioning scheme for its own -release cycle, the same way as CAPM3 and IPAM. Two braches are maintained as supported releases. +release cycle, the same way as CAPM3 and IPAM. Two branches are maintained as supported releases. Following table summarizes BMO release/test process: | Minor release | Status | @@ -77,7 +77,7 @@ Following table summarizes Ironic-image release/test process: ## Image tags The Metal³ team provides container images for all the main projects and also -many auxilary tools needed for tests or otherwise useful. Some of these images +many auxiliary tools needed for tests or otherwise useful. Some of these images are tagged in a way that makes it easy to identify what version of Cluster API provider Metal³ they are tested with. For example, we tag MariaDB container images with tags like `capm3-v1.7.0`, where `v1.7.0` would be the