|
|
Post by zephyryin on Nov 10, 2020 18:48:45 GMT
www.dmtf.org/sites/default/files/standards/documents/DSP0268_2020.3.pdfIn the redfish schema posted on 2020 March, the definition of PCIeDevice field under ComputerSystem is " This property shall contain an array of links of the
PCIeDevice type" instead of PCIeDeviceCollection, while other fields like Processors, Memory, Storage are defined as " This property shall contain a link to a resource
collection of type ****Collection." Besides, the definition of PCIeDeviceCollection includes PCIeDevices under ComputerSystem: /redfish/v1/Chassis/{ChassisId}/PCIeDevices /redfish/v1/CompositionService/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/PCIeDevices /redfish/v1/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/PCIeDevices /redfish/v1/Systems/{ComputerSystemId}/PCIeDevicesShould "/redfish/v1/Systems/{ComputerSystemId}/PCIeDevices" be an array or PCIeDeviceCollection?
|
|
|
|
Post by jautor on Nov 10, 2020 23:45:57 GMT
The descriptions are a bit confusing because of the overuse of the word "collection". For both PCIeDevices and PCIeFunctions, those links are to a "set" or "group", or some other word that means "more than one". But it's not a Resource Collection, it's an array of links to the individual devices/functions that are associated with the computer system. I'll see if we can clear up the confusion in those descriptions.
The valid link shown for a PCIeDevices Resource Collection (PCIeDeviceCollection) under Systems is valid, but we'd prefer that lives under the Chassis resource (some of those valid links pre-date the fixed URI definitions added in v1.6 of Redfish, so they're presented there for backward-compatibility).
Jeff
|
|
|
|
Post by zephyryin on Nov 11, 2020 18:15:49 GMT
Thank you for your response, does it makes more sense for ComputerSystem resource to just add a PCIeDevices link to PCIeDeviceCollection which contains an array of links to each individual PCIeDevice. This is more consistent with the representation of other resources like Processors, Memory, etc. For example: The computer system resource would looks like: { "@odata.id" : "/redfish/v1/Systems/$SystemId", "@odata.type" : "#ComputerSystem.v1_5_0.ComputerSystem", "Memory" : { "@odata.id" : "/redfish/v1/Systems/$SystemId/Memory" }, "PCIeDevices" : {
"@odata.id" : "/redfish/v1/Systems/$SystemId/PCIeDevices" }, "Processors" : { "@odata.id" : "/redfish/v1/Systems/$SystemId/Processors" }, "Storage" : {
"@odata.id" : "/redfish/v1/Systems/$SystemId/Storage" } ... } The pcie devices under computer system resource: { "@odata.id" : "/redfish/v1/$SystemId/Indus/PCIeDevices", "@odata.type" : "#PCIeDeviceCollection.PCIeDeviceCollection", "Members" : [ { "@odata.id" : "..." }, { "@odata.id" : "..." }, { "@odata.id" : "..." } ], "Members@odata.count" : 3 } |
|
|
|
Post by jautor on Nov 16, 2020 15:36:39 GMT
Thank you for your response, does it makes more sense for ComputerSystem resource to just add a PCIeDevices link to PCIeDeviceCollection which contains an array of links to each individual PCIeDevice. This is more consistent with the representation of other resources like Processors, Memory, etc. Unfortunately, no... More complex systems and fabric-connected devices will mix PCIe Devices and/or Functions - so we don't have a Collection under ComputerSystem for that reason. The Collection is under Chassis to show the physical location of the devices (the functions are under devices). But in ComputerSystem, it's an array of links to the devices/functions that apply. Hope that makes sense, Jeff |
|
|
|
Post by zephyryin on Nov 18, 2020 17:33:25 GMT
If the PCIdeDevice are array instead of resource collection, what should be the response for a GET request with the uri "/redfish/v1/Systems/$SystemId/PCIeDevices"?
|
|
|
|
Post by jautor on Nov 19, 2020 22:00:38 GMT
If the PCIdeDevice are array instead of resource collection, what should be the response for a GET request with the uri "/redfish/v1/Systems/$SystemId/PCIeDevices"? (EDIT - I misunderstood the reason for the question, so my answer was wrong) Prior to Redfish v1.6, the URIs were not specified, and when we added those requirements in v1.6, there were some locations that were in-use (and made sense), and so those were added to the list of valid URIs. For PCIeDevices, the Resource Collection may have appeared under ComputerSystem and hence that URI would return a PCIeDeviceCollection resource. But the preferred pattern for implementations is to place the PCIeDeviceCollection under Chassis: /redfish/v1/Chassis/{ChassisId}/PCIeDevices Jeff |
|
|
|
Post by zephyryin on Nov 19, 2020 23:59:18 GMT
sorry for the confusion, what I want to confirm is: should the expected response for GET uri "/redfish/v1/Systems/$SystemId/PCIeDevices" be empty?
|
|
|
|
Post by jautor on Nov 21, 2020 16:59:18 GMT
sorry for the confusion, what I want to confirm is: should the expected response for GET uri "/redfish/v1/Systems/$SystemId/PCIeDevices" be empty? While the OData specification offers the ability to retrieve single properties using that notation, it's not part of the Redfish specification nor would I expect implementations to support it. A GET on that URI would most likely return a 404 response code. |
|
