|
|
Post by zephyryin on Feb 8, 2021 19:37:02 GMT
Under the Drive schema, there is a "Protocol" field, which is a string(enum) type. There are multiple standard protocols like AHCI, ISCSI, as well as a OEM entry. Is this OEM a string or an object? If my protocol is not in the standard protocol list, can I save it in the OEM filed? Drive { Protocol {
Oem {
protocol: "my protocol"
}
}} In this way, the Drive.protocol is an object, which conflicts with the string definition, is that doable? redfish.dmtf.org/schemas/v1/Protocol.json#/definitions/Protocol |
|
|
|
Post by mraineri on Feb 9, 2021 18:34:08 GMT
Protocol is not an object. So, if you use the value "OEM", it's simply the string "OEM". If you need to convey additional information, that could be done in the "Oem" object for drive. It could be something along the lines of:
{
"Protocol": "OEM",
"Oem": {
"Contoso": {
"@odata.type": "#ContosoExtensions.v1_0_0.Drive",
"OEMProtocolInfo": "Some other descriptor for the OEM protocol..."
}
}
}One of the patterns we've been using recently for enumerations that support the value "OEM" is we also create a secondary property to help further describe the OEM value. This avoids the need for creating an OEM object like above. However, we don't have this today with Protocol.
Do you have a drive that truly supports an OEM protocol? If it's a standard protocol that we simply do not have covered today, we could also discuss adding a new enumeration value.
|
|
|
|
Post by zephyryin on Feb 9, 2021 18:55:08 GMT
Thank you for the suggestion, we have save several non-standard protocols needs to be reported in redfish, and we are planning to report it in the Drive.Oem.
|
|
|
|
Post by jautor on Feb 9, 2021 23:52:49 GMT
Thank you for the suggestion, we have save several non-standard protocols needs to be reported in redfish, and we are planning to report it in the Drive.Oem.
Are your protocols truly "non-standard"? I ask because surfacing "vendor differentiation details" in this manner may not be in your best interest. If your Drive mostly appears, for example, like a normal SAS drive in most regards, you might want it to show up alongside the other SAS drives in a system inventory. If your OEM protocol is just some additional data on top of an existing protocol - adding an "Oem" object to provide those extra details, if those are valuable to an end user, might be a better choice. That way, generic client software that wants to list "all the SAS drives in a system" won't discard it as something it doesn't understand.
Jeff
|
|
|
|
Post by Richelle Ahlvers on Feb 10, 2021 20:40:19 GMT
Following up on jautor's comment... what we are recommending to standardize representations, to ensure that clients can interpret the data more effectively, is to put the primary protocol type here (since this property only supports one value). For example, all NVMe drives should report "NVMe" here, regardless of what other potential protocols could also be supported, and put more details in other, more relevant spots in the schema. For example, an ethernet-attach NVMe drive would instead put the transport information ("Ethernet") in the network information (\Chassis\{ChassisId}\NetworkAdapters\{NetworkAdapterId}\Ports\{PortId}\...). Thanks, Richelle |
|
|
|
Post by siaoleio on Apr 1, 2021 7:56:23 GMT
Protocol is not an object. So, if you use the value "OEM", it's simply the string "OEM". If you need to convey additional information, that could be done in the "Oem" object for drive. It could be something along the lines of:
{
"Protocol": "OEM",
"Oem": {
"Contoso": {
"@odata.type": "#ContosoExtensions.v1_0_0.Drive",
"OEMProtocolInfo": "Some other descriptor for the OEM protocol..."
}
}
}One of the patterns we've been using recently for enumerations that support the value "OEM" is we also create a secondary property to help further describe the OEM value. This avoids the need for creating an OEM object like above. However, we don't have this today with Protocol.
Do you have a drive that truly supports an OEM protocol? If it's a standard protocol that we simply do not have covered today, we could also discuss adding a new enumeration value.
Hi Mraineri: I also encountered a similar problem, in the storageController object of storage resource, I need to return the SupportedControllerProtocols and SupportedDeviceProtocols properties. An official example is shown below: {
"@odata.type": "#Storage.v1_8_0.Storage",
"Id": "1",
"@odata.id": "/redfish/v1/Systems/437XR1138R2/Storage/1",
"Name": "Local Storage Controller",
"Description": "Integrated RAID Controller",
"Status": {
"State": "Enabled",
"Health": "OK",
"HealthRollup": "OK"
},
"StorageControllers": [
{
"@odata.id": "/redfish/v1/Systems/437XR1138R2/Storage/1#/StorageControllers/0",
"MemberId": "0",
"Name": "Contoso Integrated RAID",
"Status": {
"State": "Enabled",
"Health": "OK"
},
"Identifiers": [
{
"DurableNameFormat": "NAA",
"DurableName": "345C59DBD970859C"
}
],
"Manufacturer": "Contoso",
"Model": "12Gbs Integrated RAID",
"SerialNumber": "2M220100SL",
"PartNumber": "CT18754",
"SpeedGbps": 12,
"FirmwareVersion": "1.0.0.7",
"SupportedControllerProtocols": [
"PCIe"
],
"SupportedDeviceProtocols": [
"SAS",
"SATA"
]
}
]
} However, we have some protocols not listed in the offical Protocol enum object. For example, { "SupportedControllerProtocols": ["PCIe", " SPI"], "SupportedDeviceProtocols": ["SAS", "SATA", " SRIOV", "PCIx"] } We are plaining to return a payload as shown below: {
"@odata.type": "#Storage.v1_8_0.Storage",
"StorageControllers": [
{
"@odata.id": "/redfish/v1/Systems/437XR1138R2/Storage/1#/StorageControllers/0",
"MemberId": "0",
"Name": "Contoso Integrated RAID",
"Status": {
"State": "Enabled",
"Health": "OK"
},
"Identifiers": [
{
"DurableNameFormat": "NAA",
"DurableName": "345C59DBD970859C"
}
],
"Manufacturer": "Contoso",
"Model": "12Gbs Integrated RAID",
"SerialNumber": "2M220100SL",
"PartNumber": "CT18754",
"SpeedGbps": 12,
"FirmwareVersion": "1.0.0.7",
"SupportedControllerProtocols": [
"PCIe"
],
"SupportedDeviceProtocols": [
"SAS",
"SATA"
],
"Oem": {
"Contoso": {
"@odata.type": "#ContosoExtensions.v1_0_0.SupportedProtocols",
"OEMSupportedControllerProtocols": [
"SPI"
],
"OEMSupportedDeviceProtocols": [
"SRIOV",
"PCIx"
]
}
}
}
]
}
Is this ok? And do we still need to show "OEM" in the official SupportedControllerProtocols or SupportedDeviceProtocols structure? For example: {
"SupportedControllerProtocols": [
"PCIe",
"OEM" <---- should contain "OEM"?
],
"SupportedDeviceProtocols": [
"SAS",
"SATA", "OEM", "OEM" <---- if return "OEM", should I return only one "OEM" or two "OEM"?
],
"Oem": {
"Contoso": {
"@odata.type": "#ContosoExtensions.v1_0_0.SupportedProtocols",
"OEMSupportedControllerProtocols": [
"SPI"
],
"OEMSupportedDeviceProtocols": [
"SRIOV",
"PCIx"
]
}
}
}Thank you very much. |
|
|
|
Post by mraineri on Apr 1, 2021 12:26:46 GMT
For the OEM usage, you would only need one "OEM" in SupportedDeviceProtocols. That being said, I would be very cautious with some of the values you're proposing.
SRIOV isn't really a protocol; it's a way to configure virtualization of a PCIe device. The system is still using PCIe to communicate with the device (although it could be presented via a virtual function).
For PCIx, are you referring to this (https://en.wikipedia.org/wiki/PCI-X)? If so, that's something we might be able to standardize (although I'm surprised that would still be in use today).
From a system perspective, is SPI also really being used to interact with the controller? SPI might be used for management purposes, but that's probably not something you want to show in a Storage resource.
|
|
