|
Post by malbolge on Feb 1, 2020 14:37:48 GMT
DSP 0218 says:
Based on this, I'd expect the dictionary entry type for any resourceIDs properties sent by my RDE device to be of bejResourceLink type, not bejString - even though it ultimately gets converted to a Edm.String by the BMC.
If I read the code correctly, the current implementation of the DMTF dictionary builder encodes these properties (links, odata.id) as bejStrings, not bejResourceLinks. Since the dictionary is only relevant to the BMC insofar as decoding of BEJ goes, shouldn't both the returned BEJ datatype for these properties as well as the format inside of the dictionaries be bejResourceLink instead?
|
|
H.x
Minnow
Posts: 11
|
Post by H.x on Feb 1, 2020 21:46:37 GMT
Resource links looks like designed for internal resources. @odata.id is seen as string from redfish level.
Admin <--- odata.id as string --- MC
And here is 3 things: - device doesn't know api map - this data is redundant for device - MC know, needed data is only resource ID - why we have to send encoded string, if we are able to put this data in 2-3 bytes (1x nnint)
MC <--- odata.id as nnint ---- DEVICE
imo.
|
|
|
Post by bnatrajan on Feb 11, 2020 21:23:42 GMT
The issues with using nnint to represent the odata.id is that there may be "paths" to a device owned resource that the MC is not aware of. As an example, consider a storage controller that provides a Port resource via RDE. The full URI (odata.id) to the Port resource as prescribed by Redfish OpenAPI is:
/redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/StorageController/{StorageControllerMemberId}/Ports/{PortId}
Here, "/redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/" part of the URI is only known to the MC and "StorageController/{StorageControllerMemberId}/Ports/{PortId}" is only known to the device.
If the BEJ data returned by the device only contained an nnint that represents the resource id of the Port, the MC would have no way to construct this full URI.
To partially solve this problem, we introduced the notion of subURIs in the Redfish Resource PDRs. However, we came across scenarios where the MC's cache of Redfish Resource PDRs may not be in sync with the device especially if the MC does not support asynchronous eventing.
To prevent the case where a BEJ payload could contain a resource id that the MC does not (yet) know about, all odata.ids need to be constructed by the device as a bejString. It would use a deferred binding string (for the MC part of the URI) and a normal string for the device part of the URI e.g.
"%L<resource-id-of-top-level-storage>/StorageController/{StorageControllerMemberId}/Ports"
|
|
H.x
Minnow
Posts: 11
|
Post by H.x on Feb 12, 2020 2:16:49 GMT
... To partially solve this problem, we introduced the notion of subURIs in the Redfish Resource PDRs. However, we came across scenarios where the MC's cache of Redfish Resource PDRs may not be in sync with the device especially if the MC does not support asynchronous eventing. ... Would you describe those cases more detailed? RDE require Platform monitoring and control in version 1.2.0. Even if BMC doesn't support async events we still can poll for platform event messages (opcode: 0x0B, added in 1.2.0) to stay sync. While we are sync, PDRs provide for us everything to keep odata.id as resource link.
|
|
|
Post by malbolge on Feb 12, 2020 10:28:51 GMT
The issues with using nnint to represent the odata.id is that there may be "paths" to a device owned resource that the MC is not aware of. As an example, consider a storage controller that provides a Port resource via RDE. The full URI (odata.id) to the Port resource as prescribed by Redfish OpenAPI is: /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/StorageController/{StorageControllerMemberId}/Ports/{PortId}Here, " /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/" part of the URI is only known to the MC and " StorageController/{StorageControllerMemberId}/Ports/{PortId}" is only known to the device. If the BEJ data returned by the device only contained an nnint that represents the resource id of the Port, the MC would have no way to construct this full URI. To partially solve this problem, we introduced the notion of subURIs in the Redfish Resource PDRs. However, we came across scenarios where the MC's cache of Redfish Resource PDRs may not be in sync with the device especially if the MC does not support asynchronous eventing. To prevent the case where a BEJ payload could contain a resource id that the MC does not (yet) know about, all odata.ids need to be constructed by the device as a bejString. It would use a deferred binding string (for the MC part of the URI) and a normal string for the device part of the URI e.g. "%L<resource-id-of-top-level-storage>/StorageController/{StorageControllerMemberId}/Ports" This is worrying. I get a feeling the spec might be melting a bit. Followup questions then: 1) Is the BEJResourceLink datatype obsolete then? Will it be removed from DSP0218 because of redundancy or are there legitimate use cases for bejResourceLinks that cannot be achieved by the bejString representation? 2) How did it come to pass that desynchronized BMC<->RDE PDR repositories are a permissible situation? There's polling and events to make sure the BMC synchronizes in time. If the BMC still encounters unknown resources it can retrieve the PDRs post-operation, no? I am assuming that resourceIDs are not recycled within an RDE device - my RDE Toaster will always have a resourceID of 1, BreadSlots under 100 and 101 and BreadSlices will always be under resourceIDs 200 and 201. If BreadSlice 200 is removed, that resource will remain empty until a BreadSlice is inserted into that slot again, whereupon it will appear as resourceID 200 again. Is this method of operation not universally true for all RDE devices? If the concern is a TOCTOU situation where a resourceID cannot be decoded into a valid URI, then the situation is effectively still present with the bejString odata.id, since there's nothing preventing the user from removing a BreadSlice post-operation anyway, leading to a 404 URI. Worst case scenario is by the time the BMC gets the PDRs, it cannot match the ResourceID, so cannot construct a URI, so points the URI to some generic "Resource no longer exists" landing page. Ultimately, if PDRChgEvents and polling isn't enough to guarantee PDR repo sync, the BMC can just supply a checksum of it's PDR repository to OperationInit - and if that doesn't match, reject the operation and demand a PDR refresh from the BMC. A race condition is still possible if the RDE device doesn't support atomic reads though. 3) It appears that now the PDRs - the parts about related resources, subURIs and all resources which are not root-level (parent=System) specifically, are redundant. If the BMC is supposed to function fine with outdated/missing PDRs, then what purpose do they serve? What if there's a mismatch between URIs supplied via odata.id versus constructed by BMC from PDRs? Which takes precedence? What purpose do those of lesser precedence serve?
|
|
|
Post by bnatrajan on Feb 13, 2020 16:04:19 GMT
I should clarify that the primary reason for odata.id to be encoded as a bejString is the unknown sub URI case. The assumption being made is that all odata.ids would be a link to a resource that has a resource id in the RDE context. With the usage of ReferenceableMembers in Redfish, that is not true. ReferenceableMembers have a odata.id (using the frag notation) but would not be have a Resource id or PDR in RDE. Here is an example from Storage: { "@odata.id": "/redfish/v1/Systems/1/Storage/1", "@odata.type": "#Storage.v1_7_0.Storage", "Id": "1", " [email protected]": 1, "StorageControllers": [ { "@odata.id": "/redfish/v1/Systems/1/Storage/1 #/StorageControllers/0", "@odata.type": "#Storage.v1_7_0.StorageController", "FirmwareVersion": "A.B.C", ... }, { "@odata.id": "/redfish/v1/Systems/1/Storage/1 #/StorageControllers/1", "@odata.type": "#Storage.v1_7_0.StorageController", "FirmwareVersion": "A.B.D", ... } ], " [email protected]": 0, "Drives": [ ], "Volumes": { } }
|
|
H.x
Minnow
Posts: 11
|
Post by H.x on Feb 17, 2020 21:37:53 GMT
Ok, I agree that bejString can be used here for both cases. But still i don't get it, how we can get desync between device and MC. MC shall support pldmPDRRepositoryChgEvent 
|
|