[Ironic] Vendor-neutral Disk names

Mahnoor Asghar mahnoor.asghar at xflowresearch.com
Wed Jun 30 13:01:06 UTC 2021


Dear all,

There is [a proposal][1] in the metal3-io/baremetal-operator repository to
extend the hardware RAID configuration to support ‘physical_disks’ and
‘controller’ fields in the 'target_raid_config' section.
The user should be able to specify the disks for RAID configuration, in a
vendor-agnostic way. (This requirement comes from the Airship project.) The
names of the disks should be indicative of the physical location of the
disks within the server. An algorithm to construct disk names is therefore
needed, for this purpose.

One possible algorithm was found in the [inventory module][2] of the
[Redfish Tacklebox scripts][3].
To construct a disk name, it uses Redfish properties, specifically the
‘Drive’ resource> ‘Physical Location’ object> ‘Part Location’ property>
‘Service Label’ property. ([Link][4] to code) ([Link][5] to Redfish ‘Drive’
resource)
If this property is empty, the resource type (String uptil the first dot
encountered in the @odata.type field), and the ‘Id’ properties of the Drive
resource are used to construct the disk name. ([Link][6] to code)
For example, if the 'Drive'.'Physical Location'.'Part Location'.'Service
Label' field is ‘Disk.Bay1.Slot0’, this is what the disk name will be. If
this field is empty, and the resource name is ‘Drive’ and the resource ‘Id’
is ‘Disk.Bay1.Slot0’, the disk name will be: ‘Drive: Disk.Bay1.Slot0’.

We would like to understand the values different vendors give in:
   - ‘Drive’ resource> ‘Physical Location’ object> ‘Part Location’
property> ‘Service Label’ property
   - The resource type for a Drive (@odata.type field)
   - The ‘Id’ property of the Drive resource
Also, it would be helpful to understand the existing logic used by vendors
to construct the disk names, including the (Redfish or other) properties
used.

This is so that a consensus can be reached for an algorithm to construct
disk names. Any suggestions are welcome, thank you so much!

[1]: https://github.com/metal3-io/metal3-docs/pull/148
[2]:
https://github.com/DMTF/Redfish-Tacklebox/blob/master/redfish_utilities/inventory.py
[3]: https://github.com/DMTF/Redfish-Tacklebox
[4]:
https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce485ab4be37131/redfish_utilities/inventory.py#L192
[5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json
[6]:
https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce485ab4be37131/redfish_utilities/inventory.py#L199

Best regards,
Mahnoor Asghar
Software Design Engineer
xFlow Research Inc.
mahnoor.asghar at xflowresearch.com
www.xflowresearch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210630/897d6d31/attachment.html>


More information about the openstack-discuss mailing list