Merge pull request #378 from Nordix/tuomo/switch-to-markdownlint-cli2

switch markdownlint container to markdownlint-cli2

Author: metal3-io-bot

.markdownlint-cli2.yaml

@@ -0,0 +1,10 @@
+# Reference: https://github.com/DavidAnson/markdownlint-cli2#markdownlint-cli2yaml
+
+config:
+  ul-indent:
+    # Kramdown wanted us to have 3 earlier, tho this CLI recommends 2 or 4
+    indent: 3
+  line-length: false
+
+# Don't autofix anything, we're linting here
+fix: false

README.md

@@ -1,4 +1,6 @@
+<!-- markdownlint-disable no-inline-html first-line-h1 -->
 <p align="center"><img alt="Metal³" src="./images/metal3.png" /></p>
+<!-- markdownlint-enable no-inline-html first-line-h1 -->
 
 # Metal³
 

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

@@ -26,7 +26,7 @@ attempt to recover capacity.
 Hardware is imperfect, and software contains bugs. When node level failures
 such as kernel hangs or dead NICs occur, the work required from the cluster
 does not decrease - workloads from affected nodes need to be restarted
-somewhere. 
+somewhere.
 
 However some workloads may require at-most-one semantics.  Failures affecting
 these kind of workloads risk data loss and/or corruption if "lost" nodes are
@@ -41,7 +41,7 @@ that no Pods or PersistentVolumes are present there.
 Ideally customers would over-provision the cluster so that a node failure (or
 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. 
+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
 important to recover the lost capacity quickly.
@@ -106,10 +106,10 @@ See [PoC code](https://github.com/kubevirt/machine-remediation/)
 
 - A new [Machine Remediation CRD](https://github.com/kubevirt/machine-remediation/blob/master/pkg/apis/machineremediation/v1alpha1/machineremediation_types.go)
 - Two new controllers:
-  - [node
+   - [node
     reboot](https://github.com/kubevirt/machine-remediation/tree/master/pkg/controllers/nodereboot)
     which looks for the annoation and creates Machine Remediation CRs
-  - [machine
+   - [machine
     remediation](https://github.com/kubevirt/machine-remediation/tree/master/pkg/controllers/machineremediation)
     which reboots the machine and deletes the Node object (which also
     erases the signalling annotation)

design/baremetal-operator/bmh-v1beta1.md

@@ -31,7 +31,7 @@ checksums.
   the usage of `v1alpha1`.
 
 - Make the API version reflect the actual support status of the API (see
-  [alternatives](#Alternatives) for details).
+  [alternatives](#alternatives) for details).
 
 ### Non-Goals
 

design/baremetal-operator/hardware-status.md

@@ -50,14 +50,14 @@ up-to-date vision on the status of the devices.
 
 - Depending on the device, we need to collect the following
   information, when applicable:
-  - Capacity
-  - Location
-  - Manufacturer
-  - Model
-  - Part Number
-  - Serial Number
-  - Status
-  - SMART details
+   - Capacity
+   - Location
+   - Manufacturer
+   - Model
+   - Part Number
+   - Serial Number
+   - Status
+   - SMART details
 
 - NVMe drives require special tools to get SMART data (e.g. nvme-cli),
   although
@@ -107,11 +107,11 @@ up-to-date vision on the status of the devices.
   take decisions on different operations and might need a separate
   discussion on possible approaches, and includes at least the
   following aspects:
-  - Ensure correct deployment of the new service to all the members of a
+   - Ensure correct deployment of the new service to all the members of a
     cluster.
-  - Correct configuration of the service, that needs to be aware of the
+   - Correct configuration of the service, that needs to be aware of the
     ironic inspector api.
-  - Verify the service is correctly running and regularly reporting up-to-date
+   - Verify the service is correctly running and regularly reporting up-to-date
     data to ironic inspector.
 
   One possible approach would be building a new element (as part of

design/baremetal-operator/hardwaredata_crd.md

@@ -232,4 +232,4 @@ None
 - [clusterctl move](https://cluster-api.sigs.k8s.io/clusterctl/commands/move.html#clusterctl-move)
 - [Pause annotation](https://github.com/metal3-io/baremetal-operator/blob/master/docs/api.md#pausing-reconciliation)
 - [Disable inspection](https://github.com/metal3-io/metal3-docs/blob/master/design/baremetal-operator/external-introspection.md#disable-inspection-proposal)
-- [ObjectReference type](https://pkg.go.dev/k8s.io/api/core/v1#ObjectReference)
+- [ObjectReference type](https://pkg.go.dev/k8s.io/api/core/v1#ObjectReference)

design/baremetal-operator/how-ironic-works.md

@@ -160,6 +160,7 @@ This provides not only the state of the process, but also information on
 start and ending time, and more.
 An example of status answer:
 
+```json
     {
       "error": null,
       "finished": true,
@@ -174,6 +175,7 @@ An example of status answer:
       "state": "finished",
       "uuid": "c244557e-899f-46fa-a1ff-5b2c6718616b"
     }
+```
 
 There can be multiple introspection processes running at the same time, it's
 possible to retrieve all the statuses using:
@@ -229,6 +231,7 @@ through the “driver_info” option.
 
 An example of a typical node create request in JSON format:
 
+```json
     {
     "name": "test_node_dynamic",
     "driver": "ipmi",
@@ -238,6 +241,7 @@ An example of a typical node create request in JSON format:
     },
     "power_interface": "ipmitool"
     }
+```
 
 The response, if successful, contains a complete record of the node in JSON
 format with provided or default ({}, “null”, or “”) values.
@@ -257,7 +261,9 @@ All nodes in ironic are tied to a state which allows ironic to track what
 actions can be performed upon the node and convey its general disposition.
 This field is the "provision_state" field that can be retrieved via the API.
 
+```console
     GET /v1/nodes/node-id
+```
 
 Inside the returned document, a "provision_state" field can be referenced.
 Further information can be found in ironic's
@@ -272,8 +278,10 @@ 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.
 
+```console
     PUT /v1/nodes/node-id/provision/states
     {"target": "inspect"}
+```
 
 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
@@ -291,13 +299,15 @@ Starting with the bare metal node in the "available" provision_state:
    to disk. This is performed as a HTTP PATCH request to the
    `/v1/nodes/node-id` endpoint.
 
+   ```json
        {
        {“op”: “replace”, “path”: “/instance_info”, “value”: {
            “image_source”: “http://url-to-image”,
            “image_os_hash_algo”: “sha256”,
            “image_os_hash_value”: “abcdefghi…”}},
        {“op”: “replace”, “path”: “/instance_uuid”, “value”: “anyuuidvalue”}},
        }
+   ```
 
    **NOTE:** Instead of defining the "image_os_hash_*" values, a MD5 based
    image checksum can be set.
@@ -313,15 +323,19 @@ Starting with the bare metal node in the "available" provision_state:
    return code, with a message body that consists of a list of "driver"
    interfaces and any errors if applicable.
 
+   ```console
        GET /v1/nodes/node-id/validate
+   ```
 
    Reply:
 
+   ```json
        {
        "boot": true,
        ..
        "deploy": "configuration error message if applicable"
        }
+   ```
 
    The particular interfaces that would be important to pay attention to are
    ‘boot’, ‘deploy’, ‘power’, ‘management’.
@@ -352,8 +366,10 @@ Starting with the bare metal node in the "available" provision_state:
 4. Send a HTTP POST to `/v1/nodes/node-id/states/provision` to initiate
    the deployment
 
+   ```json
        {“target”: “active”,
         “configdrive”: “http://url-to-config-drive/node.iso.gz”}
+   ```
 
    Once the request to make the node active has been received by ironic,
    it will proceed with the deployment process and execute the required
@@ -392,8 +408,10 @@ erase the contents of the disks. This can be a time intensive process,
 and ultimately may only be useful for cleaning metadata except in limited
 circumstances.
 
+```console
     PUT /v1/nodes/node-id/states/provision
     {"target": "deleted"}
+```
 
 ### How to delete a baremetal node
 

design/baremetal-operator/kubebuilder-migration.md

@@ -218,14 +218,14 @@ all metal3 repositories.
 - [operator-sdk 1.0 migration guide](https://sdk.operatorframework.io/docs/building-operators/golang/project_migration_guide/)
 - [migration implementation pull request](https://github.com/metal3-io/baremetal-operator/pull/655)
 - updates to kustomize deployment files and CI fixes:
-  - <https://github.com/metal3-io/baremetal-operator/pull/672>
-  - <https://github.com/metal3-io/baremetal-operator/pull/674>
-  - <https://github.com/metal3-io/baremetal-operator/pull/675>
-  - <https://github.com/metal3-io/baremetal-operator/pull/676>
-  - <https://github.com/metal3-io/baremetal-operator/pull/677>
-  - <https://github.com/metal3-io/baremetal-operator/pull/679>
-  - <https://github.com/metal3-io/metal3-dev-env/pull/510>
-  - <https://github.com/metal3-io/cluster-api-provider-metal3/pull/137>
-  - <https://github.com/metal3-io/cluster-api-provider-metal3/pull/138>
-  - <https://github.com/metal3-io/baremetal-operator/pull/678>
+   - <https://github.com/metal3-io/baremetal-operator/pull/672>
+   - <https://github.com/metal3-io/baremetal-operator/pull/674>
+   - <https://github.com/metal3-io/baremetal-operator/pull/675>
+   - <https://github.com/metal3-io/baremetal-operator/pull/676>
+   - <https://github.com/metal3-io/baremetal-operator/pull/677>
+   - <https://github.com/metal3-io/baremetal-operator/pull/679>
+   - <https://github.com/metal3-io/metal3-dev-env/pull/510>
+   - <https://github.com/metal3-io/cluster-api-provider-metal3/pull/137>
+   - <https://github.com/metal3-io/cluster-api-provider-metal3/pull/138>
+   - <https://github.com/metal3-io/baremetal-operator/pull/678>
 - [baremetal-operator PR](https://github.com/metal3-io/baremetal-operator/pull/650)

design/baremetal-operator/raid-disk-controller.md

@@ -24,14 +24,14 @@ controllers are to be used to construct the hardware RAID volume(s).
 ### Goals
 
 The primary goal is to depict the physical disk and RAID controller names in
-the baremetal-host ``hardware-raid`` section.
+the baremetal-host `hardware-raid` section.
 
 Afterwards, implementation of the same will be done within the
-``baremetal-operator`` by extending the ``baremetal-host`` specification.
+`baremetal-operator` by extending the `baremetal-host` specification.
 
 ### Non-Goals
 
-- This specification does not deal with ``software-raid`` and extension for it.
+- This specification does not deal with `software-raid` and extension for it.
 - It does not attempt to cover any generic (vendor agnostic)  naming convention
   for disks or controllers.
 - It does not cover testing for hardware from all the vendors. It will only be
@@ -96,13 +96,13 @@ The following user story appertains to the proposal in question:
 #### Story 1
 
 As an operator, I'd like to be able to specify the physical disks and/or RAID
-controllers I want to use when defining my ``hardware-raid`` configuration, or
+controllers I want to use when defining my `hardware-raid` configuration, or
 both.
 
 ## Design Details
 
-- The CRD spec will have to be extended to add fields for ``physicalDisks`` and
-  ``controller`` under the ``hardware_raid`` section.
+- The CRD spec will have to be extended to add fields for `physicalDisks` and
+  `controller` under the `hardware_raid` section.
 - The provisioner will then be extended to process these fields.
 - The provisioner will make Ironic API calls with the RAID configuration, as
   before, but including the physical disks and controller names this time (if
@@ -116,15 +116,15 @@ there.
 
 ### Implementation Details/Notes/Constraints
 
-- Two new fields: ``Controller`` and ``PhysicalDisks`` fields will be added to
-  the ``HardwareRAIDVolume`` struct in baremetalhost_types.go.
-- Two new fields: ``Controller`` and ``PhysicalDisks`` fields will be added to
-  the ``nodes.logicalDisk`` struct being constructed in the
-  ``buildTargetHardwareRAIDCfg`` function in pkg/provisioner/ironic/raid.go.
-- A pointer to the ``RAIDConfig`` struct will be added to the
-  ``BareMetalHostStatus`` field in baremetalhost_types.go.
-- Unit test cases will be added for the ``buildTargetHardwareRAIDCfg``
-  function, in a function called ``TestBuildTargetHardwareRAIDCfg`` in
+- Two new fields: `Controller` and `PhysicalDisks` fields will be added to
+  the `HardwareRAIDVolume` struct in baremetalhost_types.go.
+- Two new fields: `Controller` and `PhysicalDisks` fields will be added to
+  the `nodes.logicalDisk` struct being constructed in the
+  `buildTargetHardwareRAIDCfg` function in pkg/provisioner/ironic/raid.go.
+- A pointer to the `RAIDConfig` struct will be added to the
+  `BareMetalHostStatus` field in baremetalhost_types.go.
+- Unit test cases will be added for the `buildTargetHardwareRAIDCfg`
+  function, in a function called `TestBuildTargetHardwareRAIDCfg` in
   pkg/provisioner/ironic/raid_test.go.
 
 ### Risks and Mitigations
@@ -135,8 +135,8 @@ undesirably remove data from disks.
 
 ### Work Items
 
-- Extend the BMH CRD spec and status, adding fields for ``physicalDisks``and
-  ``controller`` under the ``hardware_raid`` section.
+- Extend the BMH CRD spec and status, adding fields for `physicalDisks`and
+  `controller` under the `hardware_raid` section.
 - Extend the provisioner to process these fields.
 - Ensure the provisioner adds the new fields to the Ironic API call made for
   raid configuration.
@@ -151,17 +151,17 @@ undesirably remove data from disks.
 ### Test Plan
 
 The code will be tested in a development environment with a stand-alone
-deployment of the ``baremetal-operator`` and ``ironic``.  A number of
-deployments will be performed with various combinations of ``physicalDisks``
-and ``controller`` fields, and RAID levels; to test maximum possibilities.  The
+deployment of the `baremetal-operator` and `ironic`.  A number of
+deployments will be performed with various combinations of `physicalDisks`
+and `controller` fields, and RAID levels; to test maximum possibilities.  The
 RAID levels 0, 1, 5, 6, 1+0, 5+0 and 6+0 will be tested with the extended
 parameters.
 
 Unit testing will be performed to ensure that the physical disks and
 controllers added to the BMH YAML RAID configuration are added correctly to the
 `logicalDisks` field of the `nodes` object.
 
-Testing will only be performed for ``idrac-wsman``, since only that is
+Testing will only be performed for `idrac-wsman`, since only that is
 available at the moment. (i.e. with Dell EMC hardware). Other vendors will have
 to test the code accordingly.
 
@@ -183,12 +183,16 @@ None.
 
 ## Alternatives
 
-Rely on the current ``hardware-raid`` configuration which does not allow for
+Rely on the current `hardware-raid` configuration which does not allow for
 specifying physical disks and RAID controllers, but works well in use cases
 where such a functionality is not desired.
 
 ## References
 
+<!-- markdownlint-disable link-image-reference-definitions -->
+
 [1]: (https://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-PowerEdge-Boot-Optimized-Storage-Solution.pdf)
 
 [2]: (https://docs.openstack.org/ironic/latest/admin/raid.html)
+
+<!-- markdownlint-enable link-image-reference-definitions -->