Mahnoor,

How would your proposed schema work for extended storage? 

Think of the SCSI connector to JBOD.

Thanks,
Arkady

On Thu, Jul 1, 2021 at 5:29 PM Mahnoor Asghar <mahnoor.asghar@xflowresearch.com> wrote:

Thank you for the response, Mike!

I agree that 'ServiceLabel' is a good starting point, but it would be
preferable to have a more consistent format that represents a Drive
resource uniquely, irrespective of the vendor.
The idea is to let Ironic name the Drive resources using this logic,
so that the baremetal operator can use the same, consistent method of
specifying disks for RAID configuration. Feedback from the Ironic
community is very welcome here, so that an informed proposal can be
made.


On Wed, Jun 30, 2021 at 6:46 PM Mike Raineri <mraineri@gmail.com> wrote:
>
> 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@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@xflowresearch.com
>> www.xflowresearch.com



--
Mahnoor Asghar
Software Design Engineer
xFlow Research Inc.
mahnoor.asghar@xflowresearch.com
www.xflowresearch.com

--

Arkady Kanevsky, Ph.D.

Phone: 972 707-6456

Corporate Phone: 919 729-5744 ext. 8176456