[Ironic] Vendor-neutral Disk names
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/inve... [3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... Best regards, Mahnoor Asghar Software Design Engineer xFlow Research Inc. mahnoor.asghar@xflowresearch.com www.xflowresearch.com
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/inve... [3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48...
Best regards, Mahnoor Asghar Software Design Engineer xFlow Research Inc. mahnoor.asghar@xflowresearch.com www.xflowresearch.com
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/inve... [3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48...
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
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
- 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
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. 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 <
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
We would like to understand the values different vendors give in: - ‘Drive’ resource> ‘Physical Location’ object> ‘Part Location’
- 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)
mahnoor.asghar@xflowresearch.com> wrote: the resource ‘Id’ is ‘Disk.Bay1.Slot0’, the disk name will be: ‘Drive: Disk.Bay1.Slot0’. property> ‘Service Label’ property 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!
https://github.com/DMTF/Redfish-Tacklebox/blob/master/redfish_utilities/inve...
[3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48...
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
+1 to Arkady's question. Also, Software raid won't be able to be leveraged the same way, so it would need to be explicitly noted as such as a limitation. It could make a lot of sense for there to be some sort of "device name translation" code that can pass the physical devices information through/to the raid drivers, or be used in the vendor OOB raid device management drivers, at least, that is what I would expect for any common vendor independent standard to really work for handling vendor's presentation of devices inside of their BMCs. On Thu, Jul 1, 2021 at 4:23 PM Arkady Kanevsky <akanevsk@redhat.com> wrote:
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/inve... [3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48...
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
Dear Julia, Software RAID is handled separately in metal3 BMO. You're right, we can specify that as a limitation, since this naming convention will not work for software RAID. Also, we evaluated the approach you mentioned: of using disk name translation logic in the vendor drivers. We discussed it at length with Richard Pioso, Dmitry Tantsur and other community members, using generic disk names like ‘Disk 0’ etc. [1] We couldn't figure out the exact recipe of how this translation should take place. One concern with this approach was that it would be impractical to convert a constructed disk name into the vendor-specific disk name, for all the vendors. However, maybe this approach would be viable using the more verbose disk names (instead of Disk 0/1/2 initially proposed)? Out of all the possible solutions, the one we arrived at is to construct this naming convention using the Redfish schema in order to avoid vendor sprawl. The objective of this proposal is to determine how all the vendors utilize certain fields in the Redfish specification, so that we can formulate a naming convention accordingly. [1] [RFE] RAID config by Operator using generic disk numbers, and vendor-specific RAID controller names | StoryBoard (openstack.org) <https://storyboard.openstack.org/#!/story/2008866> Thank you for your response. It is very helpful. Regards, Mahnoor Asghar
Hello Arkady, The proposed schema will not work for extended storage, as the disk names would be based on physical location. Our original scheme of work only includes local storage; perhaps we can extend the work later to incorporate a naming mechanism for extended storage. Thank you for pointing this out, though! It’s a very valid point. Regards, Mahnoor Asghar On Fri, Jul 2, 2021 at 4:17 AM Arkady Kanevsky <akanevsk@redhat.com> wrote:
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
- 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
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. 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 <
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'
The user should be able to specify the disks for RAID configuration, in a vendor-agnostic way. (This requirement comes from the Airship
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
We would like to understand the values different vendors give in: - ‘Drive’ resource> ‘Physical Location’ object> ‘Part Location’
- 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)
mahnoor.asghar@xflowresearch.com> wrote: section. 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. the resource ‘Id’ is ‘Disk.Bay1.Slot0’, the disk name will be: ‘Drive: Disk.Bay1.Slot0’. property> ‘Service Label’ property 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!
https://github.com/DMTF/Redfish-Tacklebox/blob/master/redfish_utilities/inve...
[3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48... [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce48...
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
-- *Mahnoor Asghar* Software Design Engineer xFlow Research Inc. mahnoor.asghar@xflowresearch.com www.xflowresearch.com
participants (4)
-
Arkady Kanevsky
-
Julia Kreger
-
Mahnoor Asghar
-
Mike Raineri