Need to add Sunfish Core to Agent mapping and forwarding of requests

[rherrell]

We are proposing the process of updating the Sunfish Core Service's Redfish database as

1. define a complete set of 'post update' Redfish objects that reflect the intended running state of the fabric AFTER the proposed changes are made
2. POST or PATCH one or more objects (groups of objects probably manipulated using Composition Service of Aggregation Service) to Sunfish Core Service. The Entity making this request is assumed to be the Entity serializing all requests for updates to the involved objects.
3. Sunfish Core Service looks up the Agent(s) involved with accomplishing the required change(s), translates any Sunfish URIs to the appropriate Agent URIs (if only one Agent involved, should be no translations at this stage) and forwards the POST/PATCH/DELETE request to the Agent(s) and awaits a response. If the response is a notification that a Redfish Task has been launched to accomplish the Sunfish Core's request(s), Sunfish Core Service shall issue a response to the original requestor that it has launched a Redfish Task to accomplish the requestor's commands.
4. When the Agent(s) decodes the Sunfish Core request(s) it looks up the hardware manager(s) involved, translates the URIs in the Sunfish Core request(s) to the appropriate hardware manager URIs (which still may be Redfish URIs or hardware manager specific IDs), breaks down the Redfish requests into appropriate hardware manager-specific requests (which still may be Redfish CRUD commands or Actions or might be hardware-specific commands such as a CXL FM_API command), sends them to the appropriate hardware managers, and collects the responses. If the interface to the hardware managers require or encourage the Agent to use an asynchronous request format, the Agent will most likely need to create a Redfish TASK and alert Sunfish Core that a Task has been issued.
5. When the Agent(s) receive a success or failure response from the hardware managers, they update their internal Agent state, translate any IDs or Properties supplied by the hardware manager(s) to the Sunfish Core URI namespace and Property 'interpretations' (if any such are URI namespace dependent), and send the appropriate (reformatted) response to Sunfish Core. (This would be a synchronous response or an appropriate Task Complete response process).
6. Sunfish Core receives the synchronous response or retrieves the Task Complete response, translates any Agent-specific URIs to Sunfish Core URIs, updates the Sunfish Core's Redfish database accordingly (including making the update Atomic if multiple objects are impacted), and then sending the appropriate response (synchronous or Task Complete) to the original requestor.

Our reference code implementation needs a few architectural enhancements to make the above work:

• The auto generated Sunfish Core object_api.json handlers need to have the 'Agent look up and forward' feature added by the auto-generation code

• The Agent template needs to have a matching Sunfish Core interface crafted.

• The Sunfish Core and Agent reference codes need Redfish API Task Services implemented

• The Agent template needs to have the interface to multiple hardware managers architected and implemented to parallel the Sunfish to multiple Agent interfaces.

• The ability to make multi-object changes Atomic needs to be architected throughout the Sunfish/Agent/HardwareManager stack.

[christian-pinto]

I have just opened a pull request (#21) implementing most of the above points. In the specific, with the new code Sunfish can:

• Identify the agent managing a specific resource.
• Forward a request to an agent and handle success and failure (through exceptions)
• Execute any custom handlers associated to that specific object. As an example the creation of an object might also involve other changes in the sunfish internal. This is done only after the agent has successfully returned from the request

Things to be looked at as a next step are:

• making interactions between sunfish and agents more asynchronous. All is synchronous for the time being.
• handling "multi action" requests in an atomic way
• recover from agent failure