Redfish on OpenBMC

Tue Feb 6 03:58:03 AEDT 2018

Hi Ed,

Replied inline.

Hari !

From:	"Tanous, Ed" <ed.tanous at intel.com>
To:	Hariharasubramanian Ramasubramanian <hramasub at in.ibm.com>,
            "Michael.E.Brown at dell.com" <Michael.E.Brown at dell.com>
Cc:	"alirhas at microsoft.com" <alirhas at microsoft.com>,
            "Balaji.B.Rao at dell.com" <Balaji.B.Rao at dell.com>,
            "bradleyb at fuzziesquirrel.com" <bradleyb at fuzziesquirrel.com>,
            "jwcarman at us.ibm.com" <jwcarman at us.ibm.com>,
            "openbmc at lists.ozlabs.org" <openbmc at lists.ozlabs.org>,
            "Paul.Vancil at dell.com" <Paul.Vancil at dell.com>,
            "pradeep.kumar36 at tcs.com" <pradeep.kumar36 at tcs.com>,
            "rolfb at us.ibm.com" <rolfb at us.ibm.com>
Date:	02/01/2018 11:26 PM
Subject:	RE: Redfish on OpenBMC

A couple questions inline below.

-Ed

From: Hariharasubramanian Ramasubramanian [mailto:hramasub at in.ibm.com]
Sent: Thursday, February 1, 2018 1:09 AM
To: Michael.E.Brown at dell.com
Cc: alirhas at microsoft.com; Balaji.B.Rao at dell.com;
bradleyb at fuzziesquirrel.com; Tanous, Ed <ed.tanous at intel.com>;
jwcarman at us.ibm.com; openbmc at lists.ozlabs.org; Paul.Vancil at dell.com;
pradeep.kumar36 at tcs.com; rolfb at us.ibm.com
Subject: RE: Redfish on OpenBMC

Hi Michael,

Thanks for enumerating the attributes for comparison.

I want to list down a few additional criteria that may be evaluated:

1) Data-Driven Resource Discovery:
- The Redfish server should ideally build it's resource model from a
"config file". This config file could potentially be hand-coded or built
out of a "system definition file". The following are examples of system
definition files for 2 of the systems currently running OpenBMC firmware.
https://raw.githubusercontent.com/open-power/zaius-xml/master/zaius.xml
https://raw.githubusercontent.com/open-power/witherspoon-xml/master/witherspoon.xml

The system architecture (sled vs blade etc.), number of processors, number
of fans etc. can be determined from the system definition file to generate
the config file.

Are you expecting that the config file would differ significantly from the
dbus objects available on openbmc?  My running assumption was that dbus
would be the source of truth for dbus objects, and would give the avenues
for expansion.  Could we simply agree on a dbus schema, then have platforms
expose the necessary data through dbus rather than have an extensive config
file?  It seems like certain things (sensors for example) we would get the
schema for “free” and wouldn’t need to do anything redfish specific.  For
things like chassis, it might take a couple redfish specific types.

Hari>> Yes. I completely favor dbus as the means to discover the objects.
All I was suggesting that the implementation be data-driven.

That said, I find that "list" and "enumerate" are 2 *introspection* API at
the root level to discover *all* the resources. While with the Redfish API,
the discovery recurses starting at the service root, the OpenBMC REST API
is offering a flat discovery structure. The containment relationship
between resources has to be inferred from the URI path. For a resource such
as a CPU, we still need a means to identify how processors make up the
system and how many cores make up a processor/cpu.

The intent is to make the redfish implementation as system agnostic as
possible.

2) Separation of the Redfish front-end (view) and back-end (infrastructure)
layers. The infrastructure API exposed as dbus services would be one of the
means to make this separation of concerns.

Can you elaborate on this?  Do you mean separating daemons?  There are
options to expose as dbus interfaces, but the initial performance numbers
weren’t great;  And the level of control that it gave was a little
troubling for complex constructs like sensors.  I’m sure this could be
accomplished, but given the level of complexity, my team wasn’t able to
build any abstract concepts that worked well in practice.

Hari>> You are right, I was expecting the backend implementation to exposed
as dbus interfaces. Are you suggesting that this architecture has
performance bottlenecks ?

3) Performance :
- Runtime memory foot print.This could potentially have a negative impact
on "how fast" the server is. Hence the trade-off should consider what can
be cached vs what needs to be queried from the infrastructure.
In my spaces, fixed and transient memory usage is generally an order below
CPU usage, both at startup and at steady state.  I think there are some
tradeoffs to be had here, possibly invalidating caches on property change
events, but not actually regenerating them.  Things like sensors tend to be
very chatty, and coming up with a general purpose caching solution that
handles all cases gets a little difficult.

- Michael, why did you consider SSL being separately implemented by the
Redfish server? Would this be in the scope of the webserver ?

4) Eventing: Current version of the Redfish spec has left it open for the
OEMs to define the specific Event Messages. i.e. there is no standard /
common Event Registry. Redfish server implementation on the OpenBMC should
define this common Event Registry and perhaps accepted by DMTF. Does the
Eventing support filtering of events based on the event type, source
resource and the message Id ?

Agreed.

5) Leverage existing open source projects:
- Does the implementation compose existing services and frameworks ? Such
as a webserver(say, nginx) and a rest framework (flask).

In my testing, flask was a non-starter for performance on low end systems,
and while reasonably performant when measured externally with response
times, it consumed quite a bit of system CPU cycles for most tasks.  Also,
the startup time for python was suspect, and difficult to improve on
without lots of gymnastics.

Hari>> I haven't evaluated flask and it's good to know the performance
limitations with flask and python.

regards,
Hari !

Inactive hide details for ---01/31/2018 10:17:36 PM---So, I think that the
first thing we ought to do is get a survey of the di---01/31/2018 10:17:36
PM---So, I think that the first thing we ought to do is get a survey of the
different implementations tha

From: <Michael.E.Brown at dell.com>
To: <bradleyb at fuzziesquirrel.com>
Cc: <alirhas at microsoft.com>, <Balaji.B.Rao at dell.com>, <Paul.Vancil at dell.com
>, <ed.tanous at intel.com>, <rolfb at us.ibm.com>, <jwcarman at us.ibm.com>, <
hramasub at in.ibm.com>, <pradeep.kumar36 at tcs.com>, <openbmc at lists.ozlabs.org>
Date: 01/31/2018 10:17 PM
Subject: RE: Redfish on OpenBMC

So, I think that the first thing we ought to do is get a survey of the
different implementations that are out there, and establish criteria for
judging different implementations.

Here would be a list of questions I would have for everybody on the list. I
think it would probably be best to compile all of these into a wiki page
somewhere.

  - Do you have a redfish server implementation?
  - Is it Open Source?
- If not, are you planning on open sourcing it?
- What is the license?
- Is it posted to github or other public source control?
  - Does it pass the DMTF redfish service validator?
  - What language is it written in?
  - How big is it?
  - Can it be easily extended/re-used by anybody else shipping compliant
openbmc implementations?
- Can you add OEM extensions to existing Redfish Resources without
"forking" the codebase?
- Can you change the implementation for a single Redfish Resource Property
without forking?
- Can you add new Redfish Resources without forking?
  - Performance
- How fast is it?
- Does it implement SSL?
  - Security
- What is the security model?
- Non-root support? Can it run as a non-privileged user?
- Does it implement basic authentication and the redfish spec x-auth-token
authentication?
- Does it implement the redfish standard privilege map model?
  - Eventing:
- For writing a UI on top of redfish, something like SSE is a nice-to-have
to avoid polling in the browser. There are a couple of proposed SSE
extensions that have not yet been approved.
- How much work to implement SSE support to do things like watch Property
changes?
- Is the standard redfish eventing model supported?
- Security model integrated with eventing? Do eventing records get the same
security treatment as GET requests?
  - Development: can it run outside of openbmc?
  - Special sauce: is there anything not captured above that makes the
implementation special in any way?

--
Michael

-----Original Message-----
From: Brad Bishop [mailto:bradleyb at fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown at Dell.com>
Cc: alirhas at microsoft.com; Rao, Balaji B <Balaji_B_Rao at dell.com>; Vancil,
Paul <Paul_Vancil at Dell.com>; Tanous, Ed <ed.tanous at intel.com>;
rolfb at us.ibm.com; jwcarman at us.ibm.com; Hariharasubramanian Ramasubramanian
<hramasub at in.ibm.com>; pradeep.kumar36 at tcs.com; OpenBMC Maillist <
openbmc at lists.ozlabs.org>
Subject: Redfish on OpenBMC

Hi Michael

The project could really use someone to get everyone that has expressed
interest in the future of Redfish support in OpenBMC rowing in the same
direction.  So thank you for volunteering to lead that conversation at the
community call yesterday.

I’ve CC’ed everyone that I know of that has expressed an interest.
OpenBMC community: feel free to speak up if you’d like to be involved and I
forgot you.

The only thing I’d ask is to please post links to any meetings, minutes, or
correspondence here on the list, so everyone can easily keep up with how
things are going or jump in to provide feedback.

thanks again

-brad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180205/da6d7479/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180205/da6d7479/attachment-0001.gif>