Open nicklela opened 1 year ago
Yes, BMC has to handle action request from user. But I like to discussion how BIOS provide the context of /redfish/v1/Systems/SYS/Bios to BMC while this resource is empty in the beginning.
BIOS know how to provide Attributes object. @odata.XX meta data can be handled by BMC. But how about the initial value of Action attribute? Does REST to C structure generate Redfish actions automatically?
ok, I see your point. Does VFR have syntax like Action button? :)
ok, I see your point. Does VFR have syntax like Action button? :)
Yeah there is button support in VFR. But this means that we have to create a button and hide in HII (since there is no function for it in HII) I am wondering if REST to C structure can help to create action context since they are defined in schema already...
Just notice that there is no "value" defined for button op-code. Not sure how to define action link by using button op-codes. Let's discuss this during our call.
We can create a hidden string op-code to specify the location of BIOS action. For example:
So this is about how to generate the context of BIOS action while provisioning. In terms of supporting Redfish action, we certainly need BMC to help us and take HTTP POST from user. But one question comes to my mind is: if BMC can do things for us, what BMC can do so we can standardize the Redfish action support?
One idea is to convert the Redfish action to the read-only attributes in the resource. BMC takes POST action and help to update this read-only attribute. While BIOS is consuming resource, BIOS knows there is a action triggered. For eaxample:
Do we have to support that? I think we can just scope RedfishClinetPkg to support the platform configuration setting and inventory. The actions for Action POST should be taken by BMC, right?