propose node specific pre-provisioning kernel args

This commit:

- Introduces the proposal for BMH support for node specific kernel command line
  arguments for pre-provisioning images.

The motivation behind the commit can be found in the proposal.

Signed-off-by: Adam Rozman <[email protected]>

Author: Rozzii

design/baremetal-operator/node-specific-kernel-args.md

@@ -0,0 +1,166 @@
+<!--
+ This work is licensed under a Creative Commons Attribution 3.0
+ Unported License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+-->
+
+# pre-provisioning kernel argument support
+
+## Status
+
+planned
+
+## Summary
+
+This document proposes a new BareMetalHost spec attribute intended for
+configuring the pre-provisioning image's (usually IPA) kernel arguments.
+
+## Motivation
+
+There are situations where a user would need node specific kernel arguments
+for the pre-provisioning image. The reason could be the use of a mixed set of
+hardware, troubleshooting provisioning or boot issues, selectively configuring
+custom logic e.g. enabling IPA plugins or other services embedded in the
+pre-provisioning image.
+
+### Goals
+
+1. Implement a string array type optional spec field named
+   `preProvisionKernelArgs`
+2. Extend the generic `Provisioner` interface to support the new optional field
+3. Implement support for the `preProvisionKernelArgs` in the Ironic provisioner
+
+### Non-Goals
+
+1. To implement any sort value check for the new optional spec
+2. Providing a default value for the new spec field
+
+## Proposal
+
+This document proposes a new BareMetalHost spec attribute intended for
+configuring the pre-provisioning image's (usually IPA) kernel arguments.
+
+The proposal involves the introduction of a new spec field thus a modification
+to the BMO API. The API change is intended to be backward compatible as the
+new `preProvisionKernelArgs` field intended to be optional.
+
+### Implementation Details/Notes/Constraints
+
+The `preProvisionKernelArgs` field would be located directly under `spec`
+section. The format of the new field would be a list/array of individual
+strings. The new field would be optional and it would be considered
+either a NOOP or a cleaning operation depending on the previous value of the
+field in case it would be not present or have no value or would have an empty
+array as a value.
+
+The proposed BMH looks like the following:
+
+```yaml
+apiVersion: metal3.io/v1alpha1
+kind: BareMetalHost
+metadata:
+ name: bm0
+spec:
+ online: true
+ bmc:
+   address: idrac://192.168.122.1:6230/
+   credentialsName: bm0-bmc-secret
+ preProvisionKernelArgs:
+   - --timeout
+   - 60000
+   - systemd.journald.forward_to_console=yes
+   - ipa-debug=1
+   ...
+   ...
+   ...
+ bootMACAddress: 52:54:00:b7:b2:6f
+...
+...
+...
+
+```
+
+The example contains a snippet of a common IPA kernel argument list.
+The `preProvisionKernelArgs` list would be received by the `Provisioner`
+interface as is. The handling of the list would be up to the particular
+implementations of the `Provisioner` interface. In case of the `Ironic`
+provisioner the elements from the `preProvisionKernelArgs` would be
+concatenated into a single string such that the string would start with the
+first element (lowest index) from the list and would end with the last
+(highest index) element. The elements between the first and last element would
+be concatenated in an ascending order based on their index number in the array.
+
+Taken the BMH snippet from above the kernel argument list generated by
+the `Ironic provisioner` and posted to the Ironic Node API  would look like
+`--timeout 60000 systemd.journald.forward_to_console=yes ipa-debug=1 ...`.
+
+### Risks and Mitigations
+
+Providing a faulty list kernel arguments might result in boot issues
+or unexpected behavior during the life cycle of the pre-provisioning image.
+
+The user has to be aware that the kernel arguments supplied here will fully or
+partially overwrite the default arguments depending on how the particular
+`Provisioner` is handling the argument list. In case of Ironic provisioner
+the `preProvisionKernelArgs` will completely replace the default argument
+list used by Ironic.
+
+## Design Details
+
+Most of the design is very straightforward an easy to combine with the
+reconcile logic, the support for node specific pre-provisioning kernel args
+also already exist in Ironic, so right after the feature is implemented in BMO
+it can be used.
+
+The only challenge is the process of updating/cleaning the previously applied
+kernel argument list, this cleanup/update process highly depends on the
+particular provisioner but we might be able to leverage the
+`kubectl.kubernetes.io/last-applied-configuration` annotation or some other
+method to avoid initiating redundant kernel argument update,sync or cleaning
+operations.
+
+### Work Items
+
+- Implement a string array type optional spec field named
+  `preProvisionKernelArgs`
+- Extend the generic `Provisioner` interface to support the new optional field
+- Implement support for the `preProvisionKernelArgs` in the Ironic driver
+- Implement unit tests
+- Add a check to the existing BMO e2e workflow that logs in to an active IPA
+  via ssh or serial console and checks whether the custom kernel args were
+  propagated properly or not.
+
+### Dependencies
+
+- Ironic in case of the `Ironic Provisioner`
+
+### Test Plan
+
+- Unit tests for the functions
+
+- Integration testing with VMs, most likely as part of the existing
+  e2e workflow
+
+### Upgrade / Downgrade Strategy
+
+- In case of upgrade user would not need to do anything
+- In case of downgrade the user has to remove the field from the BMH
+  to both make the BMH compatible with the older API and to allow the
+  particular provisioner in use to return using the defaults arguments list.
+
+### Version Skew Strategy
+
+None
+
+## Drawbacks
+
+None
+
+## Alternatives
+
+None
+
+## Reference
+
+None