|
|
Post by igork on Jun 16, 2022 17:50:35 GMT
Hello, I'm not sure if this question has been discussed here or not. Sorry if it is duplicated. Redfish specification defines a collection of the RegistryFiles: redfish.dmtf.org/schemas/v1/MessageRegistryFileCollection.json#/definitions/MessageRegistryFileCollectionand this collection has following properties: "deletable": false, "insertable": false, "updatable": false, In our implementation AttributeRegistry file generated by FW and should be sent to BMC via Redfish Host Interface. But since this collection is not insertable then how it can be done? Thank you, Igor |
|
|
|
Post by jautor on Jun 17, 2022 17:02:13 GMT
All of those "capabilities" shown in schema (and the same answer goes for 'read-only' properties) describe what is available to the client through the Redfish interface. But internal to the service - or between the service and its various data providers, sub-services, etc. - you're free to do whatever is necessary. Clearly the BIOS and BMC (Manager) have a lot of internal information exchange to populate the data model (Processor, Memory, BIOS resource contents) - the contents of the BIOS Attribute Registry is no different.
But how that data exchange is accomplished - whether through standard interfaces or implementation-specific ones, is all "behind the scenes" and not bound to the constraints of the public-facing Redfish interface...
Jeff
|
|
|
|
Post by igork on Jun 20, 2022 14:00:26 GMT
All of those "capabilities" shown in schema (and the same answer goes for 'read-only' properties) describe what is available to the client through the Redfish interface. But internal to the service - or between the service and its various data providers, sub-services, etc. - you're free to do whatever is necessary. Clearly the BIOS and BMC (Manager) have a lot of internal information exchange to populate the data model (Processor, Memory, BIOS resource contents) - the contents of the BIOS Attribute Registry is no different. But how that data exchange is accomplished - whether through standard interfaces or implementation-specific ones, is all "behind the scenes" and not bound to the constraints of the public-facing Redfish interface... Jeff Thank you for the explanation, Jeff. |
|
|
|
Post by AMI_Mani on Jun 28, 2022 16:08:50 GMT
Hi Jeff, Based on this thread redfishforum.com/thread/308/hostinterface-privilegeregistrySo, at this time, specifically for your example with MemoryCollection and ProcessorCollection, Redfish currently does not allow anyone to perform POST operations on those resources to create Memory or Processor resources. The current language in the spec doesn't allow implementations to open that for new capabilities (you can restrict capabilities, but you cannot add capabilities). This sort of functionality is generally handled in an implementation specific manner by system firmware (BIOS/UEFI), but we've been silent in this space so far. Generally implementations have proprietary methods for registering processors and memory, and they do not use the Redfish model directly to fill in these details. It suggested to use OEM options and HI 1.3.0 specification(DSP0270_1.3.0.pdf) also has below point Host Interface and out-of-band API must be the same (where possible) so that client apps have minimal (if any) change to adapt Based on above points API was made same for Host Interface and out-of-band in redfish service. if we allow from HI, chance for user to post from OS which can override inventory provided by BIOS. Are we going to add note about this exclusion in Specification or Schema to allow post method on resources while using through Host Interface Please excuse me if any format issues and unable to format due to issues in website Thanks, Mani |
|
|
|
Post by jautor on Jun 28, 2022 23:51:06 GMT
Hi Jeff, Based on this thread redfishforum.com/thread/308/hostinterface-privilegeregistrySo, at this time, specifically for your example with MemoryCollection and ProcessorCollection, Redfish currently does not allow anyone to perform POST operations on those resources to create Memory or Processor resources. The current language in the spec doesn't allow implementations to open that for new capabilities (you can restrict capabilities, but you cannot add capabilities). Correct. But if there is a new use case that would enable a user to create/delete those types of resources, we would update that schema to reflect that potential. We don't include the "impossible" capabilities in the schema because doing so causes code generators and similar tools to produce extra output/code which will never be used. We are generally silent on the internal workings of an implementation. If you use the Host Interface to populate resources in the data model, you can restrict that access based on account credentials or some other mechanism that again, is outside the scope of the specification. That those processes would only be available in-band (from the host) and not out-of-band is not an issue, as those processes are not bound by the public-facing interfaces defined by the Redfish Specification. Jeff |
|
