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