redfish design ideas

[Michael.E.Brown at dell.com]

Definitions:
               Redfish resource: basically a single URI. For example /redfish/v1/Chassis is a single redfish resource
               Redfish property: a single named value inside a redfish resource.

Goals:
               Extensible redfish server that serves base openbmc redfish functionality (goal is Redfish OCP profile support), while at the same time should be extensible without forking so that it can be used by companies building on top of openbmc. I have been doing some proof of concept designs, and think that most of the ideas that I had been working on could be changed to fit into the existing openbmc design. Here is my simplified/brief proposal on how we can write a redfish server, for discussion. I've previously sent out the pubic github of my existing golang redfish server prototype. However, the proposal below is an extension of that prototype's ideas, I don't really intend to fully use that prototype code (it has no dbus interface, and it would probably be better to start from the ground up rather than retrofit dbus there.) Also worth mentioning: I strongly believe golang is the best way to implement this, however, there is nothing about this proposal that requires golang. It could easily be implemented in C++ if needed.

To that end, we design one daemon that presents the Redfish HTTP interface and internally exposes a DBUS API so that other daemons can publish redfish data and update redfish data (with some built-in base behaviors). The idea for this daemon is that it implements core handling of redfish json: store a tree data structure that can be marshalled to redfish JSON over HTTP, expose dbus api to manipulate that tree, and some basic behaviors controlled by metadata, ie. "get this redfish resource property from this dbus property", "call this dbus function to get this redfish resource property", "listen to signal xyz to update a redfish resource property." This daemon does not per se implement the business logic to do redfish, its purpose is to implement the core behaviours. This daemon provides methods so that other daemons can publish redfish resources (create resource, delete resource), and provides signals on events that change the resource tree (adding resources, updating properties).

Next, for implementing business logic, we can build in a few standard business logic behaviors into the standard daemon, which I'll describe below.

Note that the implementation for this can be done in a few different ways. For example, the redfish server could easily keep the entire tree in RAM and serve it from there. Or, alternatively, using the same interface, we could simply cache the redfish tree on disk in JSON files that are read as-needed. I hear some concerns with keeping the entire tree in memory. Personally, I don't feel like this is likely to be a very big issue, as the total amount of data needed to save in memory to create the default OCP profiles is a few hundred KB. However, this concern can easily be addressed by having the redfish daemon operate on saved json files in persistent storage, without changing the API at all. I have concrete data on this from my prototype server and it seems reasonable to me. Baseline was 6MB of RSS usage at runtime with the full redfish rack server mockup resident in RAM. That usage climbs to 11-12MB under heavy load and drops back down to 6MB after load is removed.

DBUS Object paths
               /redfish/v1  --> Root object
               Then, each redfish URI that is published is represented as its own object path
               /redfish/v1/Systems
               /redfish/v1/Chassis
               /redfish/v1/Accounts
                              ... etc...

Interfaces:
               org.openbmc.redfish
                              Method: CreateResource
                              Method: DeleteResource
                              Method: UpdateProperties
                              Signal: ResourceCreated
                              Signal: ResourceDeleted
                              Signal: PropertiesUpdated

Startup sequence:
               On daemon startup, it will read the saved redfish tree from the filesystem create redfish resources for each. It emits "ResourceCreated" events for each resource. The saved redfish tree has metadata for each redfish resource property to show how each property should be kept up-to-date. Additionally, other daemons on the system can listen for the ResourceCreated event and enrich the resource with additional data. For example, and OEM daemon can add new OEM properties to the resource.

OEM properties:
               Specific OEM daemons listen for signals for creation of the redfish resources they are interested in. Once they know about a base resource that they want to extend, they can use the UpdateProperties() method to add new OEM properties.

Metadata:
               In the saved redfish tree, we can tag properties so that we can automatically update them. For example, redfish resource may have a property: { "Id": "abc123" }. If this redfish property should be populated with the contents of a dbus property, we could have a metadata extension for this property like so: { "Id at metadata": { "plugin": "dbus_property", "object_path": "org.openbmc.Chassis", "property": "chassis_tag" }}. In this way, we can create different plugins to get data from different parts of the system. Note that this metadata is for the base redfish server. If more complicated things need to be done, they can be done in another daemon which creates redfish resources or modified/updates existing resources using the standard API.

Write side (PUT/PATCH/POST/DELETE):
               For each redfish resource property, the redfish server associates metadata with it to determine how to handle GET/PUT/POST/PATCH/DELETE and has some base behaviors built in that can be extended via DBUS. Base behavior is to handle PATCH/PUT by updating the internal data and emitting a PropertiesUpdated Event, POST by emitting ResourceCreated, DELETE by emitting a ResourceDeleted event. However, this behavior is probably not useful for most property updates where validation or other processing needs to take place. For this, we allow metadata to define a DBUS method to call to do the property updates. For externally created resources, the associated metadata should detail which dbus methods to call.

--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171223/a9a79518/attachment.html>