Open Stack

Hi Mahnoor,

First, to answer your questions about the property values:
- "ServiceLabel" is supposed to always be something human friendly and
matches an indicator that is used to reference a part in an enclosure.
Ultimately the vendor dictates the how they construct their
stickers/etching/silk-screens/other labels, but I would expect something
along the lines of "Drive Bay 3", or "Slot 9", or something similar.
- The resource type will always be "#Drive.v1_X_X.Drive"; this is required
by Redfish for representing a standard "Drive" resource.
- "Id" as defined in the Redfish Specification is going to be a unique
identifier in the collection; there are no rules with what goes into this
property other than uniqueness in terms of other collection members. I've
seen some implementations use a simple numeric index and others use
something that looks more like a service label. However, I've also seen a
few use either a GUID or other globally unique identifier, which might be
unfriendly for a user to look at.

With that said, when I originally authored that logic in Tacklebox, I fully
expected to revisit that logic to fine tune it to ensure it reliably gives
something human readable. I haven't gone through the exercise to refine it
further, but my initial impression is I'll be looking at more properties
specific to the Drive resource to help build the string. I think
"ServiceLabel" is still a good starting point, but having the appropriate
fallback logic in its absence would be very useful to avoid construction
based on "Id".

Thanks.

-Mike

On Wed, Jun 30, 2021 at 9:01 AM Mahnoor Asghar <
mahnoor.asghar at xflowresearch.com> wrote:

> 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/039b58bf/attachment.html>