Open Stack

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 at 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 at 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 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
>
>
>
> --
> Mahnoor Asghar
> Software Design Engineer
> xFlow Research Inc.
> mahnoor.asghar at xflowresearch.com
> www.xflowresearch.com
>
>

-- 
Arkady Kanevsky, Ph.D.
Phone: 972 707-6456
Corporate Phone: 919 729-5744 ext. 8176456
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210701/5c41d679/attachment-0001.html>