Redfish on OpenBMC

Redfish on OpenBMC

[Brad Bishop]

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

RE: Redfish on OpenBMC

[Michael.E.Brown]

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@fuzziesquirrel.com] 
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com>
Cc: alirhas@microsoft.com; Rao, Balaji B <Balaji_B_Rao@dell.com>; Vancil, Paul <Paul_Vancil@Dell.com>; Tanous, Ed <ed.tanous@intel.com>; rolfb@us.ibm.com; jwcarman@us.ibm.com; Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com>; pradeep.kumar36@tcs.com; OpenBMC Maillist <openbmc@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

RE: Redfish on OpenBMC

[Hariharasubramanian Ramasubramanian]

[-- Attachment #1.1: Type: text/plain, Size: 5689 bytes --]

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.

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.

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.
     - 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 ?

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).

regards,
Hari !




From:	<Michael.E.Brown@dell.com>
To:	<bradleyb@fuzziesquirrel.com>
Cc:	<alirhas@microsoft.com>, <Balaji.B.Rao@dell.com>,
            <Paul.Vancil@dell.com>, <ed.tanous@intel.com>,
            <rolfb@us.ibm.com>, <jwcarman@us.ibm.com>,
            <hramasub@in.ibm.com>, <pradeep.kumar36@tcs.com>,
            <openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com>
Cc: alirhas@microsoft.com; Rao, Balaji B <Balaji_B_Rao@dell.com>; Vancil,
Paul <Paul_Vancil@Dell.com>; Tanous, Ed <ed.tanous@intel.com>;
rolfb@us.ibm.com; jwcarman@us.ibm.com; Hariharasubramanian Ramasubramanian
<hramasub@in.ibm.com>; pradeep.kumar36@tcs.com; OpenBMC Maillist
<openbmc@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



[-- Attachment #1.2: Type: text/html, Size: 7744 bytes --]

[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

Re: Redfish on OpenBMC

[Deepak Kodihalli]

On 01/02/18 2:38 pm, Hariharasubramanian Ramasubramanian wrote:
> 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.

OpenBMC systems already have a "resource model" in the form of the D-Bus 
object hierarchy. Do you envision having a separate model to depict the 
Redfish hypermedia resources, or coming up with a way to map Redfish 
resources to D-Bus objects? This probably ties into the point about how 
easy it is to take the implementation and run it outside OpenBMC.

> 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.
> 
> 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.
> - 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 ?
> 
> 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).
> 
> 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@dell.com>
> To: <bradleyb@fuzziesquirrel.com>
> Cc: <alirhas@microsoft.com>, <Balaji.B.Rao@dell.com>, 
> <Paul.Vancil@dell.com>, <ed.tanous@intel.com>, <rolfb@us.ibm.com>, 
> <jwcarman@us.ibm.com>, <hramasub@in.ibm.com>, <pradeep.kumar36@tcs.com>, 
> <openbmc@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@fuzziesquirrel.com]
> Sent: Tuesday, January 30, 2018 7:30 PM
> To: Brown, Michael E <Michael_E_Brown@Dell.com>
> Cc: alirhas@microsoft.com; Rao, Balaji B <Balaji_B_Rao@dell.com>; 
> Vancil, Paul <Paul_Vancil@Dell.com>; Tanous, Ed <ed.tanous@intel.com>; 
> rolfb@us.ibm.com; jwcarman@us.ibm.com; Hariharasubramanian 
> Ramasubramanian <hramasub@in.ibm.com>; pradeep.kumar36@tcs.com; OpenBMC 
> Maillist <openbmc@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
> 
> 
> 

Regards,
Deepak

RE: Redfish on OpenBMC

[Tanous, Ed]

Answers for the bmcweb implementation inline below.

-Ed

>    - Do you have a redfish server implementation?
Yes.
>    - Is it Open Source?
Yes.

https://github.com/openbmc/bmcweb

The folder labeled redfish-core is specific to the redfish portion.

> 	- What is the license?
Apache 2.0

> 	- Is it posted to github or other public source control?
Yes

>    - Does it pass the DMTF redfish service validator?
It did 3 weeks ago;  A minor authentication bug snuck in that causes it to fail on service root, but that bug should be resolved in the next week.

>    - What language is it written in?
C++14

>    - How big is it?
Compiled and stripped size was on the order of 700KB when LTO is enabled, before filesystem compression.  This includes more than just the redfish implementation, so I would have to get some specifics on a stripped down redfish-only binary size.

>    - Can it be easily extended/re-used by anybody else shipping compliant
> openbmc implementations?
It was intended for use in OpenBmc.  There are designs to attempt to make it more generic, but those are not yet upstream.  My #1 priority is enabling OpenBmc, #2 is building a generic library that can be used outside of openbmc.

> 	- Can you add OEM extensions to existing Redfish Resources without
> "forking" the codebase?
Yes, but these extension examples are not open source yet.

> 	- Can you change the implementation for a single Redfish Resource
> Property without forking?
Nothing in the design precludes it, but it is not yet implemented.  The assumption was that data would be backed by dbus to be consistent with the other openbmc interfaces, and any modifications should be done in dbus daemons outside the webserver.

> 	- Can you add new Redfish Resources without forking?
Not really sure what this question is specifying.  Redfish resources are backed by DBus, so yes.  With that said, schemas are required to be added in code.

>    - Performance
> 	- How fast is it?
Time to first byte times are constrained by the response times of dbus and openssl as the webserver has yet to implement caching.  It seems to be relatively performant, but I haven't measured these recently on an AST2500 system.  We likely should normalize these to a single processor to avoid processor specific timing info.  My vote would be to measure all against an AST2500, as it seems to be a decent middle of the road example of a system.

> 	- Does it implement SSL?
Yes, and generates its own self signed certificate and private key on first boot.

>    - Security
> 	- What is the security model?
Authentication is handled by a single middlelayer that filters all requests before executing endpoint specific code.  Authentication is backed by pam.  Authorization and user roles are yet to be implemented, but I have patches that can be made public if people are interested.  I suspect we need to have a greater discussion around authorization for OPenBmc as a whole, and how IPMI and Redfish can share a common model.

> 	- Non-root support? Can it run as a non-privileged user?
Yes, although the patches to do this are still in review.

> 	- Does it implement basic authentication and the redfish spec x-auth-
> token authentication?
Yes.  As well it also supports cookie authentication (to host the webserver) with CSRF prevention.  Currently, both of those are required to be able to host phosphor-webui from the same server.

> 	- Does it implement the redfish standard privilege map model?
Patches to do this are in (not open source) review.  We should have a discussion about how privilege maps should be backed.

>    - 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?
It currently supports a websocket based evented endpoint that can pass propertychanged events to a browser.  Adding SSE to this implementation should be relatively easy, but I question the value add over having a websocket eventing protocol.

> 	- Is the standard redfish eventing model supported?
Not yet, but nothing in the design precludes it, and other eventing models are supported.

> 	- Security model integrated with eventing? Do eventing records get
> the same security treatment as GET requests?
Can you clarify the question a bit, I'm not sure I quite understand?  Assuming you mean that server side eventing is integrated with the rest of the auth model, yes, for websockets clients are verified on connection using cookie authentication.

>    - Development: can it run outside of openbmc?
Yes, although we're considering dropping this, as it is causing some headaches with dependency management and versioning.

>    - Special sauce: is there anything not captured above that makes the
> implementation special in any way?
Some questions we should also add:

Can it host phosphor-webui?
Yes, although a few endpoints are missing on my systems, but the authentication and login flows function, it should just be a matter of adding the 2 missing endpoints.

Does it generate a self signed SSL certificate on first boot?
Yes

Does it support websockets?  (will matter when KVM and SOL are implemented)
Yes

Is it built asynchronously in such a way that long running requests do not block quick requests?  (production requirement I've heard some people voice before)
Yes

-Ed


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

RE: Redfish on OpenBMC

[Tanous, Ed]

[-- Attachment #1.1: Type: text/plain, Size: 8655 bytes --]

A couple questions inline below.

-Ed

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

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.

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.


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@dell.com<mailto:Michael.E.Brown@dell.com>>
To: <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>
Cc: <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>, <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>, <rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>>, <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, <openbmc@lists.ozlabs.org<mailto:openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org<mailto:openbmc@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



[-- Attachment #1.2: Type: text/html, Size: 15604 bytes --]

[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Paul.Vancil]

[-- Attachment #1.1: Type: text/plain, Size: 7432 bytes --]

Michael, Brad, all,
Hello.  This is a good list of attributes and agree with Hari’s additions…
Balaji and I are in final phase of pushing our ‘RedDrum’ python Redfish service into open source with the openBMC recipes.
Im expecting to have the python code open by Mon and then next week will get the openBMC recipe in.  We are manually copying over the files now.
Next week we should be able to answer the initial list of questions for RedDrum.

Nice to see there is a lot of interest and multiple implementations coming!
Thanks
paulv

From: Hariharasubramanian Ramasubramanian [mailto:hramasub@in.ibm.com]
Sent: Thursday, February 1, 2018 3:09 AM
To: Brown, Michael E <Michael_E_Brown@Dell.com>
Cc: alirhas@microsoft.com; Rao, Balaji B <Balaji_B_Rao@dell.com>; bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; Vancil, Paul <Paul_Vancil@Dell.com>; pradeep.kumar36@tcs.com; rolfb@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.

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.

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.
- 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 ?

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).

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@dell.com<mailto:Michael.E.Brown@dell.com>>
To: <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>
Cc: <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>, <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>, <rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>>, <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, <openbmc@lists.ozlabs.org<mailto:openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org<mailto:openbmc@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



[-- Attachment #1.2: Type: text/html, Size: 14206 bytes --]

[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Ali Larijani]

[-- Attachment #1.1: Type: text/plain, Size: 8854 bytes --]

+MSFT: Chris Ong and Yugi Mani

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

Michael, Brad, all,
Hello.  This is a good list of attributes and agree with Hari’s additions…
Balaji and I are in final phase of pushing our ‘RedDrum’ python Redfish service into open source with the openBMC recipes.
Im expecting to have the python code open by Mon and then next week will get the openBMC recipe in.  We are manually copying over the files now.
Next week we should be able to answer the initial list of questions for RedDrum.

Nice to see there is a lot of interest and multiple implementations coming!
Thanks
paulv

From: Hariharasubramanian Ramasubramanian [mailto:hramasub@in.ibm.com]
Sent: Thursday, February 1, 2018 3:09 AM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>; ed.tanous@intel.com<mailto:ed.tanous@intel.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopen-power%2Fzaius-xml%2Fmaster%2Fzaius.xml&data=02%7C01%7Calirhas%40microsoft.com%7C6b626a275d0b4901593508d5699ee11f%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531053471617424&sdata=TehYNgGzaVh62ZXIryh9kaZb9ZzX37zL7%2FKats9Lu0U%3D&reserved=0>
https://raw.githubusercontent.com/open-power/witherspoon-xml/master/witherspoon.xml<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopen-power%2Fwitherspoon-xml%2Fmaster%2Fwitherspoon.xml&data=02%7C01%7Calirhas%40microsoft.com%7C6b626a275d0b4901593508d5699ee11f%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531053471617424&sdata=TivQgnXdZSJ9HoxcMjdFSDOBjCKeecvAkZHADiYuTbg%3D&reserved=0>
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.

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.

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.
- 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 ?

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).

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@dell.com<mailto:Michael.E.Brown@dell.com>>
To: <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>
Cc: <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>, <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>, <rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>>, <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, <openbmc@lists.ozlabs.org<mailto:openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org<mailto:openbmc@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


[-- Attachment #1.2: Type: text/html, Size: 16514 bytes --]

[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Hariharasubramanian Ramasubramanian]

[-- Attachment #1.1: Type: text/plain, Size: 9787 bytes --]

Hi Ed,

Replied inline.

Hari !




From:	"Tanous, Ed" <ed.tanous@intel.com>
To:	Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com>,
            "Michael.E.Brown@dell.com" <Michael.E.Brown@dell.com>
Cc:	"alirhas@microsoft.com" <alirhas@microsoft.com>,
            "Balaji.B.Rao@dell.com" <Balaji.B.Rao@dell.com>,
            "bradleyb@fuzziesquirrel.com" <bradleyb@fuzziesquirrel.com>,
            "jwcarman@us.ibm.com" <jwcarman@us.ibm.com>,
            "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
            "Paul.Vancil@dell.com" <Paul.Vancil@dell.com>,
            "pradeep.kumar36@tcs.com" <pradeep.kumar36@tcs.com>,
            "rolfb@us.ibm.com" <rolfb@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@in.ibm.com]
Sent: Thursday, February 1, 2018 1:09 AM
To: Michael.E.Brown@dell.com
Cc: alirhas@microsoft.com; Balaji.B.Rao@dell.com;
bradleyb@fuzziesquirrel.com; Tanous, Ed <ed.tanous@intel.com>;
jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; Paul.Vancil@dell.com;
pradeep.kumar36@tcs.com; rolfb@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@dell.com>
To: <bradleyb@fuzziesquirrel.com>
Cc: <alirhas@microsoft.com>, <Balaji.B.Rao@dell.com>, <Paul.Vancil@dell.com
>, <ed.tanous@intel.com>, <rolfb@us.ibm.com>, <jwcarman@us.ibm.com>, <
hramasub@in.ibm.com>, <pradeep.kumar36@tcs.com>, <openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com>
Cc: alirhas@microsoft.com; Rao, Balaji B <Balaji_B_Rao@dell.com>; Vancil,
Paul <Paul_Vancil@Dell.com>; Tanous, Ed <ed.tanous@intel.com>;
rolfb@us.ibm.com; jwcarman@us.ibm.com; Hariharasubramanian Ramasubramanian
<hramasub@in.ibm.com>; pradeep.kumar36@tcs.com; OpenBMC Maillist <
openbmc@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




[-- Attachment #1.2: Type: text/html, Size: 18003 bytes --]

[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Tanous, Ed]

[-- Attachment #1.1: Type: text/plain, Size: 13238 bytes --]

More replies inline.

-Ed

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


Hi Ed,

Replied inline.

Hari !


[Inactive hide details for "Tanous, Ed" ---02/01/2018 11:26:48 PM---A couple questions inline below. -Ed]"Tanous, Ed" ---02/01/2018 11:26:48 PM---A couple questions inline below. -Ed

From: "Tanous, Ed" <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>
To: Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, "Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>" <Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>>
Cc: "alirhas@microsoft.com<mailto:alirhas@microsoft.com>" <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>, "Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>" <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, "bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>" <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>, "jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>" <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, "openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>" <openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>>, "Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>" <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, "pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>" <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, "rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>" <rolfb@us.ibm.com<mailto:rolfb@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@in.ibm.com]
Sent: Thursday, February 1, 2018 1:09 AM
To: Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>; bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>; Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@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://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_open-2Dpower_zaius-2Dxml_master_zaius.xml&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=R95M9A3s5inBJUNXdc38WluBfQav8cUQDsgddg-niDY&s=-0M5Xc0wZo-ePshVyX993AT-2snCSlWmz84-KAF8MY8&e=>
https://raw.githubusercontent.com/open-power/witherspoon-xml/master/witherspoon.xml<https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_open-2Dpower_witherspoon-2Dxml_master_witherspoon.xml&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=R95M9A3s5inBJUNXdc38WluBfQav8cUQDsgddg-niDY&s=N-la3JJ76Cdcnw3zojpzXSP6YNQ1S2WVTCN4Xp8FeJw&e=>
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.

[Ed] I think we’re in agreement on data-driven.  Yes, the existing rest server has a flat structure, redfish is tiered and has much stricter requirements.  For something like a CPU containing sensors, the thought was that we would use dbus associations longer term.  In our prototypes right now we’re using object path, but it has some limitations and caveats about which daemon is exposing which sensor.

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 ?

[Ed] Yes, there are few bottlenecks to consider, but I think some effective use of caching might help us in the right contexts.   With that said, most of the dbus bottlenecks we’ve been able to solve with minor interface changes, or simply using the mechanisms to make calls in parallel (like GetMangedObjects).  My biggest worry from a design perspective is over optimizing the redfish server at the expense of the other system resources.

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@dell.com<mailto:Michael.E.Brown@dell.com>>
To: <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>
Cc: <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>, <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>, <rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>>, <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, <openbmc@lists.ozlabs.org<mailto:openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org<mailto:openbmc@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




[-- Attachment #1.2: Type: text/html, Size: 26879 bytes --]

[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Yugi Mani]

[-- Attachment #1.1.1: Type: text/plain, Size: 14856 bytes --]

Hi All,

Here are some more requirements based on our experience with Redfish:
1.      Concurrency
Web Server and Framework should be able to serve multiple GET requests at a time. POST/PATCH/PUT/DELETE requests can be sequential.
2.      Deterministic
Service should be time deterministic, both boot time and run time. Concurrency shall not impact deterministic property of the service. All requests shall be responded (success/failure) within acceptable time limits. Where some requests cannot be completed within time limits, service shall respond with status and expected time to complete.
3.      Cached Data
Data shall be cached by Redfish service and updated on dbus signals. Collecting required information on demand adversely impacts performance. Redfish should rather cache the information and keep updating its cache on notification from dbus that the property(ies) of interest has been modified.
4.      Platform dependent/independent layer
Shall provide a clear isolation between core vs platform properties. Can consider object oriented approach for platform & oem layer to override core methods and objects. Customized hooks and handlers can be provided by platform layer while the data model between layers is maintained consistent across platforms.
5.      DMTF Support
Redfish have quite a lot of gaps in some of the basic requirements of a BMC.

  1.  FRU & FRU Collection Schema
  2.  Sensor & Sensor Collection Schema
  3.  Component Firmware Update (PSU, BIOS, CPLD, etc)
  4.  Master Write-Read
  5.  Clear PSU Faults
We need DMTF to actively add/update Redfish schemas that are fundamental to any BMC
7.      Error Codes
Redfish LogEntry schema doesn’t offer a placeholder for error codes that automation tools can read to categorize the events and trigger actuators. One option is to reuse OEM field.
8.      Pagination
Event logs can get too big and paginated view is helpful

  1.  Filtering
Query parameter to filter the response limited to certain criteria

  1.  Anchors
Schemas like Chassis and Manager have a bunch of properties that not all requests might be interested in. It is better to be able to request just a fragment of a resource using ‘#’.

  1.  Rate Limiting

Server shall return HTTP 429 when number of requests cross max limit permissible from a client. We need some protection against Denial of Service.

Here’s our response to questions
Do you have a redfish server implementation?
[MSFT] Yes
Is it Open Source?
[MSFT] Not yet, but will be open sourced after LF transfer
If not, are you planning on open sourcing it?
[MSFT] Yes
What is the license?
[MSFT] MIT
Is it posted to github or other public source control?
[MSFT] Not yet, after LF transfer
Does it pass the DMTF redfish service validator?
[MSFT] In progress. Validator tool ran but didn’t generate a report and conformance tool need to be ported to Python 2.7.
What language is it written in?
[MSFT] Python 2.7
How big is it?
[MSFT] Size is approximately 650KB (CherryPy + Bottle), not including python, schema and templates
Can it be easily extended/re-used by anybody else shipping compliant openbmc implementations?
[MSFT] It is integrated with a fork of OpenBMC and being shipped in few expansion box products at Microsoft.
Can you add OEM extensions to existing Redfish Resources without "forking" the codebase?
[MSFT} No, it is a flat structure now and any customization would require forking
Can you change the implementation for a single Redfish Resource Property without forking?
[MSFT] No
Can you add new Redfish Resources without forking?
[MSFT] No
Performance, How fast is it?
[MSFT] Attached are some preliminary benchmarking results from one of our Redfish implementations using uwsgi as web server. We can also share similar results for another implementation with cherrypy.
Does it implement SSL?
[MSFT] Yes
What is the security model?
[MSFT] Basic authentication (user/pwd)
Non-root support? Can it run as a non-privileged user?
[MSFT] Good question. Currently it is running as root, we haven’t tried non-root though.
Does it implement basic authentication and the redfish spec x-auth-token authentication?
[MSFT] Basic auth only
Does it implement the redfish standard privilege map model?
[MSFT] We have one user only. We don’t have account service, role and privilege.
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?
[MSFT] EventService, Server-Sent Event and UI are not a requirement for us. If those were to be supported, an option to enable/disable these features as needed at build-time would be better.
Development: can it run outside of openbmc?
[MSFT] Implemented using Python 2.7, so should run on any platform. But it also tries to access local files and dbus objects. It likely would require some changes to run outside of openbmc.


Thanks,
Yugi

From: Ali Larijani
Sent: Thursday, February 1, 2018 10:29 AM
To: Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com
Cc: Balaji.B.Rao@dell.com; bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Yugi Mani <yupalani@microsoft.com>; Chris Ong <Chris.Ong@microsoft.com>
Subject: RE: Redfish on OpenBMC

+MSFT: Chris Ong and Yugi Mani

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

Michael, Brad, all,
Hello.  This is a good list of attributes and agree with Hari’s additions…
Balaji and I are in final phase of pushing our ‘RedDrum’ python Redfish service into open source with the openBMC recipes.
Im expecting to have the python code open by Mon and then next week will get the openBMC recipe in.  We are manually copying over the files now.
Next week we should be able to answer the initial list of questions for RedDrum.

Nice to see there is a lot of interest and multiple implementations coming!
Thanks
paulv

From: Hariharasubramanian Ramasubramanian [mailto:hramasub@in.ibm.com]
Sent: Thursday, February 1, 2018 3:09 AM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>; ed.tanous@intel.com<mailto:ed.tanous@intel.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopen-power%2Fzaius-xml%2Fmaster%2Fzaius.xml&data=02%7C01%7Calirhas%40microsoft.com%7C6b626a275d0b4901593508d5699ee11f%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531053471617424&sdata=TehYNgGzaVh62ZXIryh9kaZb9ZzX37zL7%2FKats9Lu0U%3D&reserved=0>
https://raw.githubusercontent.com/open-power/witherspoon-xml/master/witherspoon.xml<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopen-power%2Fwitherspoon-xml%2Fmaster%2Fwitherspoon.xml&data=02%7C01%7Calirhas%40microsoft.com%7C6b626a275d0b4901593508d5699ee11f%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531053471617424&sdata=TivQgnXdZSJ9HoxcMjdFSDOBjCKeecvAkZHADiYuTbg%3D&reserved=0>
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.

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.

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.
- 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 ?

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).

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@dell.com<mailto:Michael.E.Brown@dell.com>>
To: <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>
Cc: <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>, <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>, <rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>>, <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, <openbmc@lists.ozlabs.org<mailto:openbmc@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@fuzziesquirrel.com]
Sent: Tuesday, January 30, 2018 7:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>
Cc: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; Rao, Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org<mailto:openbmc@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

[-- Attachment #1.1.2: Type: text/html, Size: 50045 bytes --]

[-- Attachment #1.2: image001.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #2: Redfish benchmarking.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 24332 bytes --]

Re: Redfish on OpenBMC

[Michael E Brown]

On Thu, Feb 01, 2018 at 02:38:57PM +0530, Hariharasubramanian Ramasubramanian wrote:
>    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.
>    [1]https://raw.githubusercontent.com/open-power/zaius-xml/master/zaius.
>    xml
>    [2]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.
>    The intent is to make the redfish implementation as system agnostic as
>    possible.

Agreed.

I think that the intent would be for the redfish implementation to
automatically discover the system configuration based on what it finds on dbus.
If we cannot configure at runtime based on DBUS apis, then I think the
deficiency would be in the DBUS apis, but I think that ought not be a problem.

>    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.

Agreed.

>    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.

Sounds good.

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

It's just a data point. Some redfish servers might require us to have a
frontend webserver to handle frontend SSL and proxy, while others might be
appropriate to expose directly on the network.

>    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 ?

Correct, message registry would have to be delivered as part of our
implementation. Adding feature for if redfish eventing filter is supported
would be a good thing to track.

>    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).

Good.
--
Michael

>    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@dell.com>
>    To: <bradleyb@fuzziesquirrel.com>
>    Cc: <alirhas@microsoft.com>, <Balaji.B.Rao@dell.com>,
>    <Paul.Vancil@dell.com>, <ed.tanous@intel.com>, <rolfb@us.ibm.com>,
>    <jwcarman@us.ibm.com>, <hramasub@in.ibm.com>,
>    <pradeep.kumar36@tcs.com>, <openbmc@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 [[3]mailto:bradleyb@fuzziesquirrel.com]
>    Sent: Tuesday, January 30, 2018 7:30 PM
>    To: Brown, Michael E <Michael_E_Brown@Dell.com>
>    Cc: alirhas@microsoft.com; Rao, Balaji B <Balaji_B_Rao@dell.com>;
>    Vancil, Paul <Paul_Vancil@Dell.com>; Tanous, Ed <ed.tanous@intel.com>;
>    rolfb@us.ibm.com; jwcarman@us.ibm.com; Hariharasubramanian
>    Ramasubramanian <hramasub@in.ibm.com>; pradeep.kumar36@tcs.com; OpenBMC
>    Maillist <openbmc@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
> 
> References
> 
>    1. https://raw.githubusercontent.com/open-power/zaius-xml/master/zaius.xml
>    2. https://raw.githubusercontent.com/open-power/witherspoon-xml/master/witherspoon.xml
>    3. mailto:bradleyb@fuzziesquirrel.com

Re: Redfish on OpenBMC

[Michael E Brown]

On Thu, Feb 01, 2018 at 05:23:40PM +0000, Tanous, Ed wrote:
> Answers for the bmcweb implementation inline below.

All the answers for this implementation sound great. I'll have to take a closer look at the implementation.

> 
> -Ed
> 
> >    - Do you have a redfish server implementation?
> Yes.
> >    - Is it Open Source?
> Yes.
> 
> https://github.com/openbmc/bmcweb
> 
> The folder labeled redfish-core is specific to the redfish portion.
> 
> > 	- What is the license?
> Apache 2.0
> 
> > 	- Is it posted to github or other public source control?
> Yes
> 
> >    - Does it pass the DMTF redfish service validator?
> It did 3 weeks ago;  A minor authentication bug snuck in that causes it to fail on service root, but that bug should be resolved in the next week.
> 
> >    - What language is it written in?
> C++14
> 
> >    - How big is it?
> Compiled and stripped size was on the order of 700KB when LTO is enabled, before filesystem compression.  This includes more than just the redfish implementation, so I would have to get some specifics on a stripped down redfish-only binary size.
> 
> >    - Can it be easily extended/re-used by anybody else shipping compliant
> > openbmc implementations?
> It was intended for use in OpenBmc.  There are designs to attempt to make it more generic, but those are not yet upstream.  My #1 priority is enabling OpenBmc, #2 is building a generic library that can be used outside of openbmc.
> 
> > 	- Can you add OEM extensions to existing Redfish Resources without
> > "forking" the codebase?
> Yes, but these extension examples are not open source yet.

I'm curious: "not open source yet"? So, you have two forks of this codebase? It sounds like you have an internal Intel one and this one that you are migrating code between. How does that process work?

> 
> > 	- Can you change the implementation for a single Redfish Resource
> > Property without forking?
> Nothing in the design precludes it, but it is not yet implemented.  The assumption was that data would be backed by dbus to be consistent with the other openbmc interfaces, and any modifications should be done in dbus daemons outside the webserver.

I'll have to take a look at the source, because I think you interpreted the question differently than I intended.

> 
> > 	- Can you add new Redfish Resources without forking?
> Not really sure what this question is specifying.  Redfish resources are backed by DBus, so yes.  With that said, schemas are required to be added in code.
> 
> >    - Performance
> > 	- How fast is it?
> Time to first byte times are constrained by the response times of dbus and openssl as the webserver has yet to implement caching.  It seems to be relatively performant, but I haven't measured these recently on an AST2500 system.  We likely should normalize these to a single processor to avoid processor specific timing info.  My vote would be to measure all against an AST2500, as it seems to be a decent middle of the road example of a system.

I can agree on baselining the benchmarking so we compare apples to apples. I have access to only Nuvoton system, though, so I'd have to work on getting my stuff tested on AST.

> 
> > 	- Does it implement SSL?
> Yes, and generates its own self signed certificate and private key on first boot.

Nice.

> 
> >    - Security
> > 	- What is the security model?
> Authentication is handled by a single middlelayer that filters all requests before executing endpoint specific code.  Authentication is backed by pam.  Authorization and user roles are yet to be implemented, but I have patches that can be made public if people are interested.  I suspect we need to have a greater discussion around authorization for OPenBmc as a whole, and how IPMI and Redfish can share a common model.

Yes, we absolutely need to have a better discussion about how we implement a more cohesive security model.

> 
> > 	- Non-root support? Can it run as a non-privileged user?
> Yes, although the patches to do this are still in review.
> 
> > 	- Does it implement basic authentication and the redfish spec x-auth-
> > token authentication?
> Yes.  As well it also supports cookie authentication (to host the webserver) with CSRF prevention.  Currently, both of those are required to be able to host phosphor-webui from the same server.

Sounds good. I should have added in there OAuth 2.0 support, if we do OpenID Connect support at some point, it would be nice to have OAuth support to build on.

> 
> > 	- Does it implement the redfish standard privilege map model?
> Patches to do this are in (not open source) review.  We should have a discussion about how privilege maps should be backed.

Same with all of the privilege model questions.

> 
> >    - 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?
> It currently supports a websocket based evented endpoint that can pass propertychanged events to a browser.  Adding SSE to this implementation should be relatively easy, but I question the value add over having a websocket eventing protocol.

Dell is currently working on submitting SSE support to SPMF for standardization. The people I talked with were concerned that websockets were *too* general and would quickly become swamped with feature requests for everything under the sun. SSE seemed way more constrained.

> > 	- Is the standard redfish eventing model supported?
> Not yet, but nothing in the design precludes it, and other eventing models are supported.

Fair enough.

> 
> > 	- Security model integrated with eventing? Do eventing records get
> > the same security treatment as GET requests?
> Can you clarify the question a bit, I'm not sure I quite understand?  Assuming you mean that server side eventing is integrated with the rest of the auth model, yes, for websockets clients are verified on connection using cookie authentication.

Meaning, for example, a user with ReadOnly starts an SSE session, that user should only get propertychanged for redfish elements that are accessible for ReadOnly.

> >    - Development: can it run outside of openbmc?
> Yes, although we're considering dropping this, as it is causing some headaches with dependency management and versioning.

What kind of headaches?


> >    - Special sauce: is there anything not captured above that makes the
> > implementation special in any way?
> Some questions we should also add:
> 
> Can it host phosphor-webui?
> Yes, although a few endpoints are missing on my systems, but the authentication and login flows function, it should just be a matter of adding the 2 missing endpoints.

Nice.

> Does it generate a self signed SSL certificate on first boot?
> Yes

Does it do only a self-signed server cert? Or does it create a CA and then sign a server cert with the CA?

Does it pass certificate checks on curl/Linux, curl/macos, and chrome? I had to do a bit of work to ensure that everything was compatible across all of the combinations of clients. Does it populate commonName and SAN for all local IPs?


> Does it support websockets?  (will matter when KVM and SOL are implemented)
> Yes
> 
> Is it built asynchronously in such a way that long running requests do not block quick requests?  (production requirement I've heard some people voice before)
> Yes

Super important. Does it also parallelize all of the backend calls?
--
Michael

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

RE: Redfish on OpenBMC

[Tanous, Ed]

> 
> I'm curious: "not open source yet"? So, you have two forks of this codebase?
> It sounds like you have an internal Intel one and this one that you are
> migrating code between. How does that process work?
> 
There are two answers to that.  I have a short-lived fork that isn't public.  Essentially all Intel patches that you see were reviewed on our internal fork before they were pushed external.  We try to keep the lag time as short as we can (the goal is < 1 week of lag) between our master and public master for things that are considered "done".  It might be longer for short term hacks specific to our platforms.
Specifically for the more generic redfish, we started with an attempt to make it a general purpose redfish server, but hit some snags between the ideal generic solution, and getting something that worked for openbmc.  Our priority shifted a bit to a more requirements driven approach, so the "make it a general solution" work was pushed out, and the patchsets abandoned (for now).  We learned a lot from the schemas we've implemented so far, and I suspect our next run at a plugin system will go much better than the first did.

> 
> I'll have to take a look at the source, because I think you interpreted the
> question differently than I intended.
> 
I suspect the real answer depends on what you want to change.  We should probably come up with a set of use cases for OEM extensions, and see what we can implement.

> 
> I can agree on baselining the benchmarking so we compare apples to apples.
> I have access to only Nuvoton system, though, so I'd have to work on getting
> my stuff tested on AST.
> 
Happy to provide data where I can.  I did get your golang implementation running on my AST platform, and it was quite performant, just too big to be included in the main image.

> 
> Sounds good. I should have added in there OAuth 2.0 support, if we do
> OpenID Connect support at some point, it would be nice to have OAuth
> support to build on.
> 
My knowledge of OAuth support is at 10,000ft view, so I can't really evaluate if it fits into the auth model or not.  I suspect it can be made to work.

> >
> > > 	- Does it implement the redfish standard privilege map model?
> > Patches to do this are in (not open source) review.  We should have a
> discussion about how privilege maps should be backed.
> 
> Same with all of the privilege model questions.
> 
The first round of patchsets internally didn't pass code review, with that said, I will get the patchset rebased and pushed externally so others can look and provide input.

> 
> Meaning, for example, a user with ReadOnly starts an SSE session, that user
> should only get propertychanged for redfish elements that are accessible for
> ReadOnly.
> 
This should be pretty easy to adapt into just about any privilege model, assuming the proposal either reuses one of the HTTP verbs (probably GET) for determining the authorization level required for SSE, or defines a new one in the privileges json.

> > >    - Development: can it run outside of openbmc?
> > Yes, although we're considering dropping this, as it is causing some
> headaches with dependency management and versioning.
> 
> What kind of headaches?

Dependency management.  Right now we build in 2 modes, one where dependencies are pulled in through submodules, and one where dependencies are pulled in using yocto.  We've had build breakages because one got out of sync in versioning.  We've also had minor differences in gcc versions cause problems.  Unit tests throw an additionally wrench in things, and right now are not integrated with yocto builds.  There is also a desire to use c++17 features at some point, which would make it impossible to build on most people's distributions without some toolchain gymnastics.

> 
> Does it do only a self-signed server cert? Or does it create a CA and then sign
> a server cert with the CA?
> 
Right now it generates a private key and a cert, and signs with the private key.  It would only be a couple extra steps to build a CA first, but our current products don't make use of the CA today.  Do you have a use case that needs it?

> Does it pass certificate checks on curl/Linux, curl/macos, and chrome? I had
> to do a bit of work to ensure that everything was compatible across all of the
> combinations of clients. Does it populate commonName and SAN for all local
> IPs?

Right now it's self-signed, so it doesn't pass any cert checks (if I understand what you're asking).  I've used curl/Linux and chrome, and they both function with certificates verification disabled, or if the public key is installed.  Right now commonName is pulled from hostname, which is not ideal and probably should be revisited.
I never thought about populating common name with IP address, because in general the certificate is built on first boot before IP addresses are set or interfaces are enabled, and we didn't want every ip change to trigger a certificate regeneration. With that said.... if it had a CA, maybe it could regenerate without too much trouble?  I should investigate more, but in general, the self-signed cert is not recommended, and is really only there for making the web accessible in development and to upload a fully qualified SSL cert during provisioning.

> Super important. Does it also parallelize all of the backend calls?
Depends on what you mean by parallel;  In the current design, there is a single thread and an async dispatcher (based on boost io_service).  Multiple async operations can be started at a time and finish as the results are available, but the code gets really messy to write.  The best example to look at is the dbus rest implementation below.  Essentially an async transaction needs to track async transaction counts, and when the final transaction is completed (ie the count is zero), finish the HTTP request.

https://github.com/openbmc/bmcweb/blob/master/include/openbmc_dbus_rest.hpp

RE: Redfish on OpenBMC

[Ali Larijani]

+Microsoft team

-----Original Message-----
From: Tanous, Ed <ed.tanous@intel.com> 
Sent: Tuesday, February 6, 2018 9:28 AM
To: Michael E Brown <Michael.E.Brown@dell.com>
Cc: bradleyb@fuzziesquirrel.com; rolfb@us.ibm.com; pradeep.kumar36@tcs.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; Paul.Vancil@dell.com; Ali Larijani <alirhas@microsoft.com>; Balaji.B.Rao@dell.com
Subject: RE: Redfish on OpenBMC

> 
> I'm curious: "not open source yet"? So, you have two forks of this codebase?
> It sounds like you have an internal Intel one and this one that you 
> are migrating code between. How does that process work?
> 
There are two answers to that.  I have a short-lived fork that isn't public.  Essentially all Intel patches that you see were reviewed on our internal fork before they were pushed external.  We try to keep the lag time as short as we can (the goal is < 1 week of lag) between our master and public master for things that are considered "done".  It might be longer for short term hacks specific to our platforms.
Specifically for the more generic redfish, we started with an attempt to make it a general purpose redfish server, but hit some snags between the ideal generic solution, and getting something that worked for openbmc.  Our priority shifted a bit to a more requirements driven approach, so the "make it a general solution" work was pushed out, and the patchsets abandoned (for now).  We learned a lot from the schemas we've implemented so far, and I suspect our next run at a plugin system will go much better than the first did.

> 
> I'll have to take a look at the source, because I think you 
> interpreted the question differently than I intended.
> 
I suspect the real answer depends on what you want to change.  We should probably come up with a set of use cases for OEM extensions, and see what we can implement.

> 
> I can agree on baselining the benchmarking so we compare apples to apples.
> I have access to only Nuvoton system, though, so I'd have to work on 
> getting my stuff tested on AST.
> 
Happy to provide data where I can.  I did get your golang implementation running on my AST platform, and it was quite performant, just too big to be included in the main image.

> 
> Sounds good. I should have added in there OAuth 2.0 support, if we do 
> OpenID Connect support at some point, it would be nice to have OAuth 
> support to build on.
> 
My knowledge of OAuth support is at 10,000ft view, so I can't really evaluate if it fits into the auth model or not.  I suspect it can be made to work.

> >
> > > 	- Does it implement the redfish standard privilege map model?
> > Patches to do this are in (not open source) review.  We should have 
> > a
> discussion about how privilege maps should be backed.
> 
> Same with all of the privilege model questions.
> 
The first round of patchsets internally didn't pass code review, with that said, I will get the patchset rebased and pushed externally so others can look and provide input.

> 
> Meaning, for example, a user with ReadOnly starts an SSE session, that 
> user should only get propertychanged for redfish elements that are 
> accessible for ReadOnly.
> 
This should be pretty easy to adapt into just about any privilege model, assuming the proposal either reuses one of the HTTP verbs (probably GET) for determining the authorization level required for SSE, or defines a new one in the privileges json.

> > >    - Development: can it run outside of openbmc?
> > Yes, although we're considering dropping this, as it is causing some
> headaches with dependency management and versioning.
> 
> What kind of headaches?

Dependency management.  Right now we build in 2 modes, one where dependencies are pulled in through submodules, and one where dependencies are pulled in using yocto.  We've had build breakages because one got out of sync in versioning.  We've also had minor differences in gcc versions cause problems.  Unit tests throw an additionally wrench in things, and right now are not integrated with yocto builds.  There is also a desire to use c++17 features at some point, which would make it impossible to build on most people's distributions without some toolchain gymnastics.

> 
> Does it do only a self-signed server cert? Or does it create a CA and 
> then sign a server cert with the CA?
> 
Right now it generates a private key and a cert, and signs with the private key.  It would only be a couple extra steps to build a CA first, but our current products don't make use of the CA today.  Do you have a use case that needs it?

> Does it pass certificate checks on curl/Linux, curl/macos, and chrome? 
> I had to do a bit of work to ensure that everything was compatible 
> across all of the combinations of clients. Does it populate commonName 
> and SAN for all local IPs?

Right now it's self-signed, so it doesn't pass any cert checks (if I understand what you're asking).  I've used curl/Linux and chrome, and they both function with certificates verification disabled, or if the public key is installed.  Right now commonName is pulled from hostname, which is not ideal and probably should be revisited.
I never thought about populating common name with IP address, because in general the certificate is built on first boot before IP addresses are set or interfaces are enabled, and we didn't want every ip change to trigger a certificate regeneration. With that said.... if it had a CA, maybe it could regenerate without too much trouble?  I should investigate more, but in general, the self-signed cert is not recommended, and is really only there for making the web accessible in development and to upload a fully qualified SSL cert during provisioning.

> Super important. Does it also parallelize all of the backend calls?
Depends on what you mean by parallel;  In the current design, there is a single thread and an async dispatcher (based on boost io_service).  Multiple async operations can be started at a time and finish as the results are available, but the code gets really messy to write.  The best example to look at is the dbus rest implementation below.  Essentially an async transaction needs to track async transaction counts, and when the final transaction is completed (ie the count is zero), finish the HTTP request.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fbmcweb%2Fblob%2Fmaster%2Finclude%2Fopenbmc_dbus_rest.hpp&data=02%7C01%7Calirhas%40microsoft.com%7Ce5a6c5fa67aa4d74f83908d56d86f2f8%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535348742656043&sdata=adTjMu%2F75%2BMcgYGhVjJbVzMh1r8V72IMTJub464QAVs%3D&reserved=0

RE: Redfish on OpenBMC

[Yugi Mani]

On 01/31/2018 10:17 PM Michael Brown <Michael.E.Brown@dell.com> wrote:
> Do you have a redfish server implementation?
Yes

> Is it Open Source?
Not yet, but will be open sourced after LF transfer

> If not, are you planning on open sourcing it?
Yes

> What is the license?
MIT

> Is it posted to github or other public source control?
Not yet, after LF transfer

> Does it pass the DMTF redfish service validator?
In progress. Validator tool ran but didn’t generate a report and 
conformance tool need to be ported to Python 2.7.

> What language is it written in?
Python 2.7

> How big is it?
Size is approximately 650KB (CherryPy + Bottle), 
not including python, schema and templates

> Can it be easily extended/re-used by anybody else shipping 
> compliant openbmc implementations?
It is integrated with a fork of OpenBMC and being shipped 
in few expansion box products at Microsoft.

> Can you add OEM extensions to existing Redfish Resources 
> without "forking" the codebase?
No, it is a flat structure now and any customization would require forking

> Can you change the implementation for a single Redfish Resource Property 
> without forking?
No

> Can you add new Redfish Resources without forking?
No

> Performance
> How fast is it?
Synchronous API for Sensors and SEL takes longer to respond. 
It takes about 19 seconds for 100 sensors and more than 6 minutes for 4000 events. 
10 concurrent requests can make them 4-5 times slower than usual. 
Asynchronous API for BMC and component firmware update takes 5-10 minutes as expected. 
These results are on AST2400. 

> Does it implement SSL?
Yes

> Security
> What is the security model?
Basic authentication (user/pwd)

> Non-root support? Can it run as a non-privileged user?
Good question. Currently it is running as root, we haven’t tried non-root though. 
Since you asked, we might as well would like to start this service as non-root. 

> Does it implement basic authentication and the redfish spec x-auth-token authentication?
Basic auth only. Token auth is not a requirement for us at this time. 

> Does it implement the redfish standard privilege map model?
We have one user only. We don’t have account service, role and privilege. 
Multiple users and roles are not a requirement for us at this time. 

> 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?
EventService, Server-Sent Event and UI are not a requirement for us. 
If those were to be supported, an option to enable/disable 
these features as needed at build-time would be better.

> Development: can it run outside of openbmc?
Implemented using Python 2.7, so should run on any platform. 
But it also tries to access local files and dbus objects. 
It likely would require some changes to run outside of openbmc.

-Yugi

RE: Redfish on OpenBMC

[Yugi Mani]

Here are some more requirements based on our experience with Redfish:
1. Concurrency
Web Server and Framework should be able to serve multiple GET requests at a time. 
POST/PATCH/PUT/DELETE requests can be sequential. 

2. Deterministic
Service should be time deterministic, both boot time and run time. 
Concurrency shall not impact deterministic property of the service. 
All requests shall be responded (success/failure) within acceptable time limits. 
Where some requests cannot be completed within time limits, 
service shall respond with status and expected time to complete. 

3. Cached Data
Data shall be cached by Redfish service and updated on dbus signals. 
Collecting required information on demand adversely impacts performance. 
Redfish should rather cache the information and keep updating its cache 
on notification from dbus that the property(ies) of interest has been modified. 

4. Platform dependent/independent layer
Shall provide a clear isolation between core vs platform properties. 
Can consider object oriented approach for platform & oem layer 
to override core methods and objects. Customized hooks and handlers 
can be provided by platform layer while the data model 
between layers is maintained consistent across platforms. 

5. DMTF Support
Redfish have quite a lot of gaps in some of the basic requirements of a BMC. 
a) FRU & FRU Collection Schema
b) Sensor & Sensor Collection Schema
c) Component Firmware Update (PSU, BIOS, CPLD, etc)
d) Master Write-Read
e) Clear PSU Faults
We need DMTF to actively add/update Redfish schemas that are fundamental to any BMC.

7. Error Codes
Redfish LogEntry schema doesn’t offer a placeholder for error codes 
that automation tools can read to categorize the events and trigger actuators. 
One option is to repurpose OEM field. 

8. Pagination
Event logs can get too big and paginated view is helpful

9. Filtering
Query parameter to filter the response limited to certain criteria

10. Anchors
Schemas like Chassis and Manager have a bunch of properties 
that not all requests might be interested in. 
It is better to be able to request just a fragment of a resource using ‘#’. 

11. Rate Limiting
Server shall return HTTP 429 when number of requests cross max limit permissible from a client. 
We need some protection against Denial of Service.

-Yugi

RE: Redfish on OpenBMC

[Tanous, Ed]

> > Performance
> > How fast is it?
> Synchronous API for Sensors and SEL takes longer to respond.
> It takes about 19 seconds for 100 sensors and more than 6 minutes for 4000
> events.
> 10 concurrent requests can make them 4-5 times slower than usual.
> Asynchronous API for BMC and component firmware update takes 5-10
> minutes as expected.
> These results are on AST2400.

Do you have the same data for your 2500 platforms?

RE: Redfish on OpenBMC

[Chris Ong]

Hi Ed,

On our AST2520 platform:
Reading sensors using Redfish takes about 12-13 seconds for about 200 sensors. If 10 threads are requesting the read at the same time, the average time to return is about 70 seconds.

For reading logs, it takes about 100 seconds for 4000 log entries. The time scales linearly with the number of logs, e.g. for 2000 logs, it would take around 50s.

Chris

-----Original Message-----
From: Tanous, Ed <ed.tanous@intel.com> 
Sent: Wednesday, February 7, 2018 8:09 AM
To: Yugi Mani <yupalani@microsoft.com>; Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com
Cc: Balaji.B.Rao@dell.com; bradleyb@fuzziesquirrel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong <Chris.Ong@microsoft.com>
Subject: RE: Redfish on OpenBMC

> > Performance
> > How fast is it?
> Synchronous API for Sensors and SEL takes longer to respond.
> It takes about 19 seconds for 100 sensors and more than 6 minutes for 
> 4000 events.
> 10 concurrent requests can make them 4-5 times slower than usual.
> Asynchronous API for BMC and component firmware update takes 5-10 
> minutes as expected.
> These results are on AST2400.

Do you have the same data for your 2500 platforms?

Re: Redfish on OpenBMC

[Rolf Brudeseth]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

> 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 !
>
Are other language options besides Python an alternative, such as Golang? It has webserver and template functionality built-in so an additional framework may not be required.

It is compiled so it should have better performance than Python. Cross-compiling to ARM is trivial.

Rolf


[-- Attachment #2: Type: text/html, Size: 2163 bytes --]

Re: Redfish on OpenBMC

[Hariharasubramanian Ramasubramanian]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]



"openbmc" <openbmc-bounces+hramasub=in.ibm.com@lists.ozlabs.org> wrote on
02/08/2018 09:55:18 AM:

> From: Rolf Brudeseth <code@brudeseth.name>
> To: openbmc@lists.ozlabs.org
> Date: 02/08/2018 10:23 AM
> Subject: Re: Redfish on OpenBMC
> Sent by: "openbmc" <openbmc-bounces+hramasub=in.ibm.com@lists.ozlabs.org>
>
> 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 !

> Are other language options besides Python an alternative, such as
> Golang? It has webserver and template functionality built-in so an
> additional framework may not be required.
>
> It is compiled so it should have better performance than Python.
> Cross-compiling to ARM is trivial.
>
> Rolf
There certainly is no precedence for golang based code in OpenBMC yet.
But that shouldn't stop us from exploring that. I believe Michael's
implementation is golang based as well.
Hari !

[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

RE: Redfish on OpenBMC

[Rapkiewicz, Pawel]

Hi Chris, Yugi,

Thanks for your benchmarking you've attached, I'd like to better understand the data. I'm curious about 10 concurrent requests for redfish root service. The average is ~5 seconds for uwsgi, and mostly no response for gevent.
Few questions:
- gevent and uwsgi, those are two independent redfish server implementations?
- do you have any traffic during retrieving root service?
- Was it with Basic HTTP Auth, or without any?

I'm also little confused on how do we measure and present code size and performance, since it's not normalized anyhow, it's biased by the measurement method. If the intent of gathering those data is to
compare different Redfish approaches, we shall consider setting the measure criteria. Some suggestions:

Code size:
- real code size, not on compressed file system
- is it binary or script?
- what's the size of dependent libraries (already existing in OpenBMC environment vs. the new one required only by given Redfish implementation)?

Performance:
- We need common script for measurement
- And common method, I'd prefer running on machine directly connected to the OpenBMC platform to minimize network latency, or to run it over loopback interface on the platform, but this may affect context switching
- The performance will still be biased by the CPU the Redfish is running, but it will be closer to make it comparable.

Regards,
Pawel


-----Original Message-----
From: openbmc [mailto:openbmc-bounces+pawel.rapkiewicz=intel.com@lists.ozlabs.org] On Behalf Of Chris Ong
Sent: Wednesday, February 7, 2018 5:15 PM
To: Tanous, Ed <ed.tanous@intel.com>; Yugi Mani <yupalani@microsoft.com>; Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com
Cc: rolfb@us.ibm.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; bradleyb@fuzziesquirrel.com; Balaji.B.Rao@dell.com
Subject: RE: Redfish on OpenBMC

Hi Ed,

On our AST2520 platform:
Reading sensors using Redfish takes about 12-13 seconds for about 200 sensors. If 10 threads are requesting the read at the same time, the average time to return is about 70 seconds.

For reading logs, it takes about 100 seconds for 4000 log entries. The time scales linearly with the number of logs, e.g. for 2000 logs, it would take around 50s.

Chris

-----Original Message-----
From: Tanous, Ed <ed.tanous@intel.com>
Sent: Wednesday, February 7, 2018 8:09 AM
To: Yugi Mani <yupalani@microsoft.com>; Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com
Cc: Balaji.B.Rao@dell.com; bradleyb@fuzziesquirrel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong <Chris.Ong@microsoft.com>
Subject: RE: Redfish on OpenBMC

> > Performance
> > How fast is it?
> Synchronous API for Sensors and SEL takes longer to respond.
> It takes about 19 seconds for 100 sensors and more than 6 minutes for
> 4000 events.
> 10 concurrent requests can make them 4-5 times slower than usual.
> Asynchronous API for BMC and component firmware update takes 5-10 
> minutes as expected.
> These results are on AST2400.

Do you have the same data for your 2500 platforms?

--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

RE: Redfish on OpenBMC

[Hariharasubramanian Ramasubramanian]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]




"Rapkiewicz, Pawel" <pawel.rapkiewicz@intel.com> wrote on 02/08/2018
07:47:02 PM:


> Thanks for your benchmarking you've attached, I'd like to better
> understand the data. I'm curious about 10 concurrent requests for
> redfish root service. The average is ~5 seconds for uwsgi, and
> mostly no response for gevent.
> Few questions:
> - gevent and uwsgi, those are two independent redfish server
implementations?
> - do you have any traffic during retrieving root service?
> - Was it with Basic HTTP Auth, or without any?
>
I gather Microsoft implementation supports only Basic Auth. Redfish
requires all requests (apart from requests for service root, metadata and
session establishment) to be authenticated. Hence I surmise that the
performance results are "with Basic HTTP Auth".

Hari !

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

RE: Redfish on OpenBMC

[Yugi Mani]

On Thursday, February 8, 2018 6:17 AM, Rapkiewicz, Pawel [pawel.rapkiewicz@intel.com] wrote:

> - gevent and uwsgi, those are two independent redfish server
> implementations?
Yes, we had gevent and uwsgi on AST2400. 
gevent and cherrypy on AST2500. 
Chris's results are using cherrypy. 
We are not supporting gevent anymore on both platforms because of its lack of concurrency ability. 

> - do you have any traffic during retrieving root service?
System Under Test (SUT) was on corporate network. System might have received some broadcast packets, but shouldn't have received any unicast packets except for Redfish commands. 

> - Was it with Basic HTTP Auth, or without any?
As Hari identified before service root requests were unauthenticated and other requests that we benchmarked were with basic auth. 

> Code size:
> - real code size, not on compressed file system
We set this flag "BB_GENERATE_MIRROR_TARBALLS" in our conf file. Size I sent was for tar file. 

> - what's the size of dependent libraries (already existing in OpenBMC
> environment vs. the new one required only by given Redfish
> implementation)?
I will calculate and let you know. 

 > Performance:
> - We need common script for measurement
If you are using curl on linux, them "time curl ..." would do. 

> - And common method, I'd prefer running on machine directly
> connected to the OpenBMC platform to minimize network latency, or to
> run it over loopback interface on the platform, but this may affect
> context switching
We did it on regular corporate network. 

> - The performance will still be biased by the CPU the Redfish is running,
> but it will be closer to make it comparable.
There are lots of parameters that can affect Redfish response time - number of processes running, priority of redfish service, size of response, how redfish gathers response data, what is the format of source data, apart from CPU & Network that you identified. 
It is really hard to do apples-apples as you said. 

Re: Redfish on OpenBMC

[Michael E Brown]

On Thu, Feb 08, 2018 at 02:17:02PM +0000, Rapkiewicz, Pawel wrote:
> Hi Chris, Yugi,
> 
> Thanks for your benchmarking you've attached, I'd like to better understand the data. I'm curious about 10 concurrent requests for redfish root service. The average is ~5 seconds for uwsgi, and mostly no response for gevent.
> Few questions:
> - gevent and uwsgi, those are two independent redfish server implementations?
> - do you have any traffic during retrieving root service?
> - Was it with Basic HTTP Auth, or without any?
> 
> I'm also little confused on how do we measure and present code size and performance, since it's not normalized anyhow, it's biased by the measurement method. If the intent of gathering those data is to
> compare different Redfish approaches, we shall consider setting the measure criteria. Some suggestions:
> 
> Code size:
> - real code size, not on compressed file system
> - is it binary or script?
> - what's the size of dependent libraries (already existing in OpenBMC environment vs. the new one required only by given Redfish implementation)?
> 
> Performance:
> - We need common script for measurement
> - And common method, I'd prefer running on machine directly connected to the OpenBMC platform to minimize network latency, or to run it over loopback interface on the platform, but this may affect context switching
> - The performance will still be biased by the CPU the Redfish is running, but it will be closer to make it comparable.
> 
> Regards,
> Pawel
> 
> 
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+pawel.rapkiewicz=intel.com@lists.ozlabs.org] On Behalf Of Chris Ong
> Sent: Wednesday, February 7, 2018 5:15 PM
> To: Tanous, Ed <ed.tanous@intel.com>; Yugi Mani <yupalani@microsoft.com>; Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com
> Cc: rolfb@us.ibm.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; bradleyb@fuzziesquirrel.com; Balaji.B.Rao@dell.com
> Subject: RE: Redfish on OpenBMC
> 
> Hi Ed,
> 
> On our AST2520 platform:
> Reading sensors using Redfish takes about 12-13 seconds for about 200 sensors. If 10 threads are requesting the read at the same time, the average time to return is about 70 seconds.
> 
> For reading logs, it takes about 100 seconds for 4000 log entries. The time scales linearly with the number of logs, e.g. for 2000 logs, it would take around 50s.
> 
> Chris


I'm basically ready to post some numbers for my redfish stack. I was busy beavering away trying to make sure I had at least enough stuff implemented to give a good idea of both the performance as well as implementation difficulty.

Here are my stats:

Language: golang
Source: https://github.com/superchalupa/go-redfish
Runtime RSS: 11MB RAM at rest, 16MB under load.
Binary size: lz compressed: <3MB, uncompressed 11MB

I have a few different benchmark numbers. First, the script I'm using is https://github.com/superchalupa/go-redfish/blob/master/scripts/walk.sh, the time reported is just the time from 'curl' reporting the total request time. Also, my results are running on the Nuvoton Poleg, I would expect times to be slower running on AST. I've put build instructions in the readme.

First of all, the HTTP (no compression) results in an average response time of 0.003 seconds.

For HTTPS, I have two results. First, the native golang SSL stack, which is poorly optimized for 32-bit ARM, results in average requests of about 0.250 per request. Next, I used the golang "spacemonkeygo" openssl wrapper to serve using the more-optimized openssl libraries. This results in 0.150s per request.

And, finally, interesting to note is if you pipeline your requests. For curl, this would be simply putting multiple requests on one command line. For these, the results are that the first request hits at the time for HTTPS (either 0.250 or 0.150 depending on which implementation you use), and the subsequent requests all come in around 0.003s. This means an entire redfish walk can be done in less than a second for my test implementation.

Notes on implementation:

I've implemented thermal using the openbmc dbus xyz.openbmc-project.Sensor.Value interface and using mapper to dynamically construct the thermal sensors available. It appears that it ought to be quick and easy to do the same for fans. I've also implemented a few other dbus calls, such as the Manager.Reset action.

Mostly the implementation caches values. Because of information from Ed that subscribing to events might not result in nice systemwide properties, right now I refresh sensor values on a configurable timer (10s right now).

The more things I've implemented with this implementation, the more I'm liking how nicely things are shaking out, and I'm finally to the point where I can focus on trying to get some other people up to speed on the codebase rather than trying ot get all the basics running.

Thoughts?

I'll post the actual test results shortly, I lost the machine I was using for benchmarking due to a network issue and cannot access it until tomorrow.
--
Michael

Re: Redfish on OpenBMC

[Michael E Brown]

On Thu, Feb 08, 2018 at 11:21:50AM +0530, Hariharasubramanian Ramasubramanian wrote:
>  "openbmc" <openbmc-bounces+hramasub=in.ibm.com@lists.ozlabs.org> wrote
>  > From: Rolf Brudeseth <code@brudeseth.name>
>  > Golang? It has webserver and template functionality built-in so an
>  > additional framework may not be required.
>  >
>  > It is compiled so it should have better performance than Python.
>  > Cross-compiling to ARM is trivial.
>  >
>  > Rolf
>  There certainly is no precedence for golang based code in OpenBMC yet.
>  But that shouldn't stop us from exploring that. I believe Michael's
>  implementation is golang based as well.

Indeed. My implementation is at https://github.com/superchalupa/go-redfish/

It is in golang and it is trivial to cross compile for ARM. Build instructions
are now in the README.

Additionally, as detailed in my previous email, if you have cross openssl
library available, you can compile against that purely for additional speed.
(2x as fast!) There is a helper script scripts/build-arm.sh that I made for
that.

After a few weeks of work, I think that I'm finally ready for additional people
to help. With most projects, there is a minimum level of functionality that has
to be in place before you can start bringing other people on, and I finally
feel like I'm at that point.

--
Michael

Re: Redfish on OpenBMC

[Michael E Brown]

Stats for go-redfish running on Nuvoton Poleg. First, processor stats. Since we agreed on AST2500 as the baseline, I don't have one of those to do benchmarks. If somebody could run the benchmarks on an AST2500 that would be very helpful.

$ cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

processor       : 1
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : NPCMX50 Chip family
Revision        : 0000
Serial          : 0000000000000000

Go-redfish was checked out per the readme on https://github.com/superchalupa/go-redfish and built like this:

$ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh

Using the 'openssl' based HTTPS support because it's faster on 32-bit ARM. For x86 and 64-bit ARM, go native SSL is almost equal in performance. Read the readme for details.

I use a benchmark tool called 'hey': https://github.com/rakyll/hey, it is a load generator. You can install it like this: "go get github.com/rakyll/hey". It will put 'hey' in $GOPATH/bin/. The go-redfish server supports the redfish standard X-Auth-Token as well as Basic auth. The benchmarks below are using basic auth in the interest of brevity, but it's also simple to benchmark tokens. The numbers don't appear much different.

Here is a run against the most complicated output currently implemented. This run is for 10 seconds, with the default concurrency of 50 parallel requests. The result is that the average request is 0.1588s and the server handles an average of 312 requests per second.

$ hey -z 10s  https://Administrator:password@10.35.174.126:8443/redfish/v1/Chassis/A33/Thermal                            
Summary:
  Total:        10.1230 secs
  Slowest:      1.9524 secs
  Fastest:      0.0051 secs
  Average:      0.1588 secs
  Requests/sec: 312.8521

Response time histogram:
  0.005 [1]     |
  0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.395 [31]    |
  0.589 [5]     |
  0.784 [9]     |
  0.979 [10]    |
  1.173 [9]     |
  1.368 [8]     |
  1.563 [5]     |
  1.758 [2]     |
  1.952 [25]    |

Latency distribution:
  10% in 0.0840 secs
  25% in 0.1159 secs
  50% in 0.1374 secs
  75% in 0.1576 secs
  90% in 0.1748 secs
  95% in 0.1874 secs
  99% in 1.3962 secs

Details (average, fastest, slowest):
  DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs
  DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:     0.0000 secs, 0.0000 secs, 0.0007 secs
  resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs
  resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200] 3167 responses


The memory usage of the program under load (Resident size, IOW, RAM usage during load is roughly 16MB):

# cat /proc/$(pidof ocp-server.arm)/status
Name:   ocp-server.arm
Umask:  0022
State:  S (sleeping)
Tgid:   2737
Ngid:   0
Pid:    2737
PPid:   2710
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0 
VmPeak:  1167212 kB
VmSize:  1167212 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     16924 kB
VmRSS:     16844 kB
RssAnon:            9200 kB
RssFile:            1788 kB
RssShmem:           5856 kB
VmData:   395108 kB
VmStk:       136 kB
VmExe:      6304 kB
VmLib:      2792 kB
VmPTE:       130 kB
VmPMD:         0 kB
VmSwap:        0 kB
Threads:        45
SigQ:   0/3577
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7bfa7a25
SigIgn: 0000000000000000
SigCgt: ffffffffffc1feff
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Cpus_allowed:   3
Cpus_allowed_list:      0-1
voluntary_ctxt_switches:        92
nonvoluntary_ctxt_switches:     21

The binary size is 10MB uncompressed and 2MB compressed (xz level 9)

$ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz
$ ls -l ocp-server.arm*
-rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052 Feb 14 13:14 ocp-server.arm
-rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26 ocp-server.arm.xz

The source is currently sitting at under 5k LoC implementing a few proof of concept openbmc implementations calling DBUS, as well as a simulation.

Concurrency:
- Highly concurrent. On ARM serves >300 requests per second. On X86, goes up to about 3k requests per second
- For individual requests: can concurrently get data from multiple data sources and runs all the plugins for a redfish resource in parallel

Deterministic:
- The design should be fairly deterministic.

Cached:
- Completely flexible here. The default model is caching the data, but it's also supported to make dbus calls per request (though that's not really recommended). Currently it caches sensor results and refreshes those at a fixed interval, though that could easily be changed.

Platform dependent/independent:
- Core is completely platform independent.
- Working on an OCP profile implementation that also has platform independent + platform specific hooks. Currently in place are simulation implementation plus openbmc dbus implementation for sensors (temperature now, working fans next).

DMTF support:
- In progress. Help needed.

--
Michael

On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:
> Here are some more requirements based on our experience with Redfish:
> 1. Concurrency
> Web Server and Framework should be able to serve multiple GET requests at a time. 
> POST/PATCH/PUT/DELETE requests can be sequential. 
> 
> 2. Deterministic
> Service should be time deterministic, both boot time and run time. 
> Concurrency shall not impact deterministic property of the service. 
> All requests shall be responded (success/failure) within acceptable time limits. 
> Where some requests cannot be completed within time limits, 
> service shall respond with status and expected time to complete. 
> 
> 3. Cached Data
> Data shall be cached by Redfish service and updated on dbus signals. 
> Collecting required information on demand adversely impacts performance. 
> Redfish should rather cache the information and keep updating its cache 
> on notification from dbus that the property(ies) of interest has been modified. 
> 
> 4. Platform dependent/independent layer
> Shall provide a clear isolation between core vs platform properties. 
> Can consider object oriented approach for platform & oem layer 
> to override core methods and objects. Customized hooks and handlers 
> can be provided by platform layer while the data model 
> between layers is maintained consistent across platforms. 
> 
> 5. DMTF Support
> Redfish have quite a lot of gaps in some of the basic requirements of a BMC. 
> a) FRU & FRU Collection Schema
> b) Sensor & Sensor Collection Schema
> c) Component Firmware Update (PSU, BIOS, CPLD, etc)
> d) Master Write-Read
> e) Clear PSU Faults
> We need DMTF to actively add/update Redfish schemas that are fundamental to any BMC.
> 
> 7. Error Codes
> Redfish LogEntry schema doesn’t offer a placeholder for error codes 
> that automation tools can read to categorize the events and trigger actuators. 
> One option is to repurpose OEM field. 
> 
> 8. Pagination
> Event logs can get too big and paginated view is helpful
> 
> 9. Filtering
> Query parameter to filter the response limited to certain criteria
> 
> 10. Anchors
> Schemas like Chassis and Manager have a bunch of properties 
> that not all requests might be interested in. 
> It is better to be able to request just a fragment of a resource using ‘#’. 
> 
> 11. Rate Limiting
> Server shall return HTTP 429 when number of requests cross max limit permissible from a client. 
> We need some protection against Denial of Service.
> 
> -Yugi

RE: Redfish on OpenBMC

[Ali Larijani]

Hi everybody,
Can I propose we get together on a call to discuss a  plan moving forward with Redfish implementation? 
Do you see any value of having a weekly sync up call?

Thanks
Ali
-----Original Message-----
From: Michael E Brown <Michael.E.Brown@dell.com> 
Sent: Wednesday, February 14, 2018 11:37 AM
To: Yugi Mani <yupalani@microsoft.com>
Cc: Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com; Balaji.B.Rao@dell.com; bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong <Chris.Ong@microsoft.com>
Subject: Re: Redfish on OpenBMC

Stats for go-redfish running on Nuvoton Poleg. First, processor stats. Since we agreed on AST2500 as the baseline, I don't have one of those to do benchmarks. If somebody could run the benchmarks on an AST2500 that would be very helpful.

$ cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

processor       : 1
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : NPCMX50 Chip family
Revision        : 0000
Serial          : 0000000000000000

Go-redfish was checked out per the readme on https://github.com/superchalupa/go-redfish and built like this:

$ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh

Using the 'openssl' based HTTPS support because it's faster on 32-bit ARM. For x86 and 64-bit ARM, go native SSL is almost equal in performance. Read the readme for details.

I use a benchmark tool called 'hey': https://github.com/rakyll/hey, it is a load generator. You can install it like this: "go get github.com/rakyll/hey". It will put 'hey' in $GOPATH/bin/. The go-redfish server supports the redfish standard X-Auth-Token as well as Basic auth. The benchmarks below are using basic auth in the interest of brevity, but it's also simple to benchmark tokens. The numbers don't appear much different.

Here is a run against the most complicated output currently implemented. This run is for 10 seconds, with the default concurrency of 50 parallel requests. The result is that the average request is 0.1588s and the server handles an average of 312 requests per second.

$ hey -z 10s  https://Administrator:password@10.35.174.126:8443/redfish/v1/Chassis/A33/Thermal                            
Summary:
  Total:        10.1230 secs
  Slowest:      1.9524 secs
  Fastest:      0.0051 secs
  Average:      0.1588 secs
  Requests/sec: 312.8521

Response time histogram:
  0.005 [1]     |
  0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.395 [31]    |
  0.589 [5]     |
  0.784 [9]     |
  0.979 [10]    |
  1.173 [9]     |
  1.368 [8]     |
  1.563 [5]     |
  1.758 [2]     |
  1.952 [25]    |

Latency distribution:
  10% in 0.0840 secs
  25% in 0.1159 secs
  50% in 0.1374 secs
  75% in 0.1576 secs
  90% in 0.1748 secs
  95% in 0.1874 secs
  99% in 1.3962 secs

Details (average, fastest, slowest):
  DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs
  DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:     0.0000 secs, 0.0000 secs, 0.0007 secs
  resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs
  resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200] 3167 responses


The memory usage of the program under load (Resident size, IOW, RAM usage during load is roughly 16MB):

# cat /proc/$(pidof ocp-server.arm)/status
Name:   ocp-server.arm
Umask:  0022
State:  S (sleeping)
Tgid:   2737
Ngid:   0
Pid:    2737
PPid:   2710
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0
VmPeak:  1167212 kB
VmSize:  1167212 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     16924 kB
VmRSS:     16844 kB
RssAnon:            9200 kB
RssFile:            1788 kB
RssShmem:           5856 kB
VmData:   395108 kB
VmStk:       136 kB
VmExe:      6304 kB
VmLib:      2792 kB
VmPTE:       130 kB
VmPMD:         0 kB
VmSwap:        0 kB
Threads:        45
SigQ:   0/3577
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7bfa7a25
SigIgn: 0000000000000000
SigCgt: ffffffffffc1feff
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Cpus_allowed:   3
Cpus_allowed_list:      0-1
voluntary_ctxt_switches:        92
nonvoluntary_ctxt_switches:     21

The binary size is 10MB uncompressed and 2MB compressed (xz level 9)

$ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz $ ls -l ocp-server.arm* -rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052 Feb 14 13:14 ocp-server.arm
-rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26 ocp-server.arm.xz

The source is currently sitting at under 5k LoC implementing a few proof of concept openbmc implementations calling DBUS, as well as a simulation.

Concurrency:
- Highly concurrent. On ARM serves >300 requests per second. On X86, goes up to about 3k requests per second
- For individual requests: can concurrently get data from multiple data sources and runs all the plugins for a redfish resource in parallel

Deterministic:
- The design should be fairly deterministic.

Cached:
- Completely flexible here. The default model is caching the data, but it's also supported to make dbus calls per request (though that's not really recommended). Currently it caches sensor results and refreshes those at a fixed interval, though that could easily be changed.

Platform dependent/independent:
- Core is completely platform independent.
- Working on an OCP profile implementation that also has platform independent + platform specific hooks. Currently in place are simulation implementation plus openbmc dbus implementation for sensors (temperature now, working fans next).

DMTF support:
- In progress. Help needed.

--
Michael

On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:
> Here are some more requirements based on our experience with Redfish:
> 1. Concurrency
> Web Server and Framework should be able to serve multiple GET requests at a time. 
> POST/PATCH/PUT/DELETE requests can be sequential. 
> 
> 2. Deterministic
> Service should be time deterministic, both boot time and run time. 
> Concurrency shall not impact deterministic property of the service. 
> All requests shall be responded (success/failure) within acceptable time limits. 
> Where some requests cannot be completed within time limits, service 
> shall respond with status and expected time to complete.
> 
> 3. Cached Data
> Data shall be cached by Redfish service and updated on dbus signals. 
> Collecting required information on demand adversely impacts performance. 
> Redfish should rather cache the information and keep updating its 
> cache on notification from dbus that the property(ies) of interest has been modified.
> 
> 4. Platform dependent/independent layer Shall provide a clear 
> isolation between core vs platform properties.
> Can consider object oriented approach for platform & oem layer to 
> override core methods and objects. Customized hooks and handlers can 
> be provided by platform layer while the data model between layers is 
> maintained consistent across platforms.
> 
> 5. DMTF Support
> Redfish have quite a lot of gaps in some of the basic requirements of a BMC. 
> a) FRU & FRU Collection Schema
> b) Sensor & Sensor Collection Schema
> c) Component Firmware Update (PSU, BIOS, CPLD, etc)
> d) Master Write-Read
> e) Clear PSU Faults
> We need DMTF to actively add/update Redfish schemas that are fundamental to any BMC.
> 
> 7. Error Codes
> Redfish LogEntry schema doesn’t offer a placeholder for error codes 
> that automation tools can read to categorize the events and trigger actuators.
> One option is to repurpose OEM field. 
> 
> 8. Pagination
> Event logs can get too big and paginated view is helpful
> 
> 9. Filtering
> Query parameter to filter the response limited to certain criteria
> 
> 10. Anchors
> Schemas like Chassis and Manager have a bunch of properties that not 
> all requests might be interested in.
> It is better to be able to request just a fragment of a resource using ‘#’. 
> 
> 11. Rate Limiting
> Server shall return HTTP 429 when number of requests cross max limit permissible from a client. 
> We need some protection against Denial of Service.
> 
> -Yugi

RE: Redfish on OpenBMC

[Michael.E.Brown]

Yes, I think it would be valuable to have a call. Do you have a time proposal? I can host from Dell skype.

Proposed time slots. Here are a variety that personally work ok for me. Votes?
	Monday 4pm CST
	Wed evening 9pm CST
	Thursday morning 9am CST
	Thursday 12pm CST
	Friday 8am CST
--
Michael

-----Original Message-----
From: Ali Larijani [mailto:alirhas@microsoft.com] 
Sent: Thursday, February 22, 2018 3:54 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com>; Yugi Mani <yupalani@microsoft.com>
Cc: Vancil, Paul <Paul_Vancil@Dell.com>; hramasub@in.ibm.com; Rao, Balaji B <Balaji_B_Rao@dell.com>; bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong <Chris.Ong@microsoft.com>
Subject: RE: Redfish on OpenBMC

Hi everybody,
Can I propose we get together on a call to discuss a  plan moving forward with Redfish implementation? 
Do you see any value of having a weekly sync up call?

Thanks
Ali
-----Original Message-----
From: Michael E Brown <Michael.E.Brown@dell.com>
Sent: Wednesday, February 14, 2018 11:37 AM
To: Yugi Mani <yupalani@microsoft.com>
Cc: Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; hramasub@in.ibm.com; Michael.E.Brown@dell.com; Balaji.B.Rao@dell.com; bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong <Chris.Ong@microsoft.com>
Subject: Re: Redfish on OpenBMC

Stats for go-redfish running on Nuvoton Poleg. First, processor stats. Since we agreed on AST2500 as the baseline, I don't have one of those to do benchmarks. If somebody could run the benchmarks on an AST2500 that would be very helpful.

$ cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

processor       : 1
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : NPCMX50 Chip family
Revision        : 0000
Serial          : 0000000000000000

Go-redfish was checked out per the readme on https://github.com/superchalupa/go-redfish and built like this:

$ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh

Using the 'openssl' based HTTPS support because it's faster on 32-bit ARM. For x86 and 64-bit ARM, go native SSL is almost equal in performance. Read the readme for details.

I use a benchmark tool called 'hey': https://github.com/rakyll/hey, it is a load generator. You can install it like this: "go get github.com/rakyll/hey". It will put 'hey' in $GOPATH/bin/. The go-redfish server supports the redfish standard X-Auth-Token as well as Basic auth. The benchmarks below are using basic auth in the interest of brevity, but it's also simple to benchmark tokens. The numbers don't appear much different.

Here is a run against the most complicated output currently implemented. This run is for 10 seconds, with the default concurrency of 50 parallel requests. The result is that the average request is 0.1588s and the server handles an average of 312 requests per second.

$ hey -z 10s  https://Administrator:password@10.35.174.126:8443/redfish/v1/Chassis/A33/Thermal                            
Summary:
  Total:        10.1230 secs
  Slowest:      1.9524 secs
  Fastest:      0.0051 secs
  Average:      0.1588 secs
  Requests/sec: 312.8521

Response time histogram:
  0.005 [1]     |
  0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.395 [31]    |
  0.589 [5]     |
  0.784 [9]     |
  0.979 [10]    |
  1.173 [9]     |
  1.368 [8]     |
  1.563 [5]     |
  1.758 [2]     |
  1.952 [25]    |

Latency distribution:
  10% in 0.0840 secs
  25% in 0.1159 secs
  50% in 0.1374 secs
  75% in 0.1576 secs
  90% in 0.1748 secs
  95% in 0.1874 secs
  99% in 1.3962 secs

Details (average, fastest, slowest):
  DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs
  DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:     0.0000 secs, 0.0000 secs, 0.0007 secs
  resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs
  resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200] 3167 responses


The memory usage of the program under load (Resident size, IOW, RAM usage during load is roughly 16MB):

# cat /proc/$(pidof ocp-server.arm)/status
Name:   ocp-server.arm
Umask:  0022
State:  S (sleeping)
Tgid:   2737
Ngid:   0
Pid:    2737
PPid:   2710
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0
VmPeak:  1167212 kB
VmSize:  1167212 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     16924 kB
VmRSS:     16844 kB
RssAnon:            9200 kB
RssFile:            1788 kB
RssShmem:           5856 kB
VmData:   395108 kB
VmStk:       136 kB
VmExe:      6304 kB
VmLib:      2792 kB
VmPTE:       130 kB
VmPMD:         0 kB
VmSwap:        0 kB
Threads:        45
SigQ:   0/3577
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7bfa7a25
SigIgn: 0000000000000000
SigCgt: ffffffffffc1feff
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Cpus_allowed:   3
Cpus_allowed_list:      0-1
voluntary_ctxt_switches:        92
nonvoluntary_ctxt_switches:     21

The binary size is 10MB uncompressed and 2MB compressed (xz level 9)

$ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz $ ls -l ocp-server.arm* -rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052 Feb 14 13:14 ocp-server.arm
-rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26 ocp-server.arm.xz

The source is currently sitting at under 5k LoC implementing a few proof of concept openbmc implementations calling DBUS, as well as a simulation.

Concurrency:
- Highly concurrent. On ARM serves >300 requests per second. On X86, goes up to about 3k requests per second
- For individual requests: can concurrently get data from multiple data sources and runs all the plugins for a redfish resource in parallel

Deterministic:
- The design should be fairly deterministic.

Cached:
- Completely flexible here. The default model is caching the data, but it's also supported to make dbus calls per request (though that's not really recommended). Currently it caches sensor results and refreshes those at a fixed interval, though that could easily be changed.

Platform dependent/independent:
- Core is completely platform independent.
- Working on an OCP profile implementation that also has platform independent + platform specific hooks. Currently in place are simulation implementation plus openbmc dbus implementation for sensors (temperature now, working fans next).

DMTF support:
- In progress. Help needed.

--
Michael

On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:
> Here are some more requirements based on our experience with Redfish:
> 1. Concurrency
> Web Server and Framework should be able to serve multiple GET requests at a time. 
> POST/PATCH/PUT/DELETE requests can be sequential. 
> 
> 2. Deterministic
> Service should be time deterministic, both boot time and run time. 
> Concurrency shall not impact deterministic property of the service. 
> All requests shall be responded (success/failure) within acceptable time limits. 
> Where some requests cannot be completed within time limits, service 
> shall respond with status and expected time to complete.
> 
> 3. Cached Data
> Data shall be cached by Redfish service and updated on dbus signals. 
> Collecting required information on demand adversely impacts performance. 
> Redfish should rather cache the information and keep updating its 
> cache on notification from dbus that the property(ies) of interest has been modified.
> 
> 4. Platform dependent/independent layer Shall provide a clear 
> isolation between core vs platform properties.
> Can consider object oriented approach for platform & oem layer to 
> override core methods and objects. Customized hooks and handlers can 
> be provided by platform layer while the data model between layers is 
> maintained consistent across platforms.
> 
> 5. DMTF Support
> Redfish have quite a lot of gaps in some of the basic requirements of a BMC. 
> a) FRU & FRU Collection Schema
> b) Sensor & Sensor Collection Schema
> c) Component Firmware Update (PSU, BIOS, CPLD, etc)
> d) Master Write-Read
> e) Clear PSU Faults
> We need DMTF to actively add/update Redfish schemas that are fundamental to any BMC.
> 
> 7. Error Codes
> Redfish LogEntry schema doesn’t offer a placeholder for error codes 
> that automation tools can read to categorize the events and trigger actuators.
> One option is to repurpose OEM field. 
> 
> 8. Pagination
> Event logs can get too big and paginated view is helpful
> 
> 9. Filtering
> Query parameter to filter the response limited to certain criteria
> 
> 10. Anchors
> Schemas like Chassis and Manager have a bunch of properties that not 
> all requests might be interested in.
> It is better to be able to request just a fragment of a resource using ‘#’. 
> 
> 11. Rate Limiting
> Server shall return HTTP 429 when number of requests cross max limit permissible from a client. 
> We need some protection against Denial of Service.
> 
> -Yugi

RE: Redfish on OpenBMC

[Tanous, Ed]

Hah, you guys beat me to it.

My preference would be Monday at 4pm CST, 2PM PST, but I think I can make any of them that aren't Wednesday.

Also, If I'm reading this correct, this email only went out to a few of us.  Once we have a time, we should post it to the main email list as well.
I'm also happy to host if Michael can't.  BlueJeans seemed to work quite well for the TSC meetings, so I was thinking of doing that for sharing.


 Here was the email I was typing up yesterday:

I’d like to start a Redfish working group for OpenBMC.

Primary goals of this working group will be:
1.	Disseminate information on various redfish implementations for OpenBMC
2.	Discuss technical requirements and implementation specifics
3.	Make an effort to consolidate work on a “phosphor” OpenBMC redfish implementation

Initial Agenda for the first meeting will be

Initial introductions
Overview of existing implementations and work
	Bmcweb implementation by Intel – Ed Tanous
	Go-redfish implementation by Dell – Michael Brown
	Redfish implementation by Microsoft – Ali Larijani/Yugi Mani/Bryan Kelly
	Others?

Meeting time and frequency.
	Daily/Weekly/monthly/quarterly?
	What times work for the most people?

Consolidated requirements
	Do we want/need them?
	How will we handle them?
	How will we discuss architectural changes?

Language choice
	Python/C++/Golang preferences?

Other Topics?

> -----Original Message-----
> From: Michael.E.Brown@dell.com [mailto:Michael.E.Brown@dell.com]
> Sent: Thursday, February 22, 2018 2:03 PM
> To: alirhas@microsoft.com; yupalani@microsoft.com
> Cc: Paul.Vancil@dell.com; hramasub@in.ibm.com; Balaji.B.Rao@dell.com;
> bradleyb@fuzziesquirrel.com; Tanous, Ed <ed.tanous@intel.com>;
> jwcarman@us.ibm.com; openbmc@lists.ozlabs.org;
> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris.Ong@microsoft.com
> Subject: RE: Redfish on OpenBMC
> 
> Yes, I think it would be valuable to have a call. Do you have a time proposal? I
> can host from Dell skype.
> 
> Proposed time slots. Here are a variety that personally work ok for me.
> Votes?
> 	Monday 4pm CST
> 	Wed evening 9pm CST
> 	Thursday morning 9am CST
> 	Thursday 12pm CST
> 	Friday 8am CST
> --
> Michael
> 
> -----Original Message-----
> From: Ali Larijani [mailto:alirhas@microsoft.com]
> Sent: Thursday, February 22, 2018 3:54 PM
> To: Brown, Michael E <Michael_E_Brown@Dell.com>; Yugi Mani
> <yupalani@microsoft.com>
> Cc: Vancil, Paul <Paul_Vancil@Dell.com>; hramasub@in.ibm.com; Rao, Balaji
> B <Balaji_B_Rao@dell.com>; bradleyb@fuzziesquirrel.com;
> ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org;
> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong
> <Chris.Ong@microsoft.com>
> Subject: RE: Redfish on OpenBMC
> 
> Hi everybody,
> Can I propose we get together on a call to discuss a  plan moving forward
> with Redfish implementation?
> Do you see any value of having a weekly sync up call?
> 
> Thanks
> Ali
> -----Original Message-----
> From: Michael E Brown <Michael.E.Brown@dell.com>
> Sent: Wednesday, February 14, 2018 11:37 AM
> To: Yugi Mani <yupalani@microsoft.com>
> Cc: Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com;
> hramasub@in.ibm.com; Michael.E.Brown@dell.com; Balaji.B.Rao@dell.com;
> bradleyb@fuzziesquirrel.com; ed.tanous@intel.com;
> jwcarman@us.ibm.com; openbmc@lists.ozlabs.org;
> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong
> <Chris.Ong@microsoft.com>
> Subject: Re: Redfish on OpenBMC
> 
> Stats for go-redfish running on Nuvoton Poleg. First, processor stats. Since
> we agreed on AST2500 as the baseline, I don't have one of those to do
> benchmarks. If somebody could run the benchmarks on an AST2500 that
> would be very helpful.
> 
> $ cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 1 (v7l)
> BogoMIPS        : 1594.16
> Features        : half thumb fastmult edsp tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x4
> CPU part        : 0xc09
> CPU revision    : 1
> 
> processor       : 1
> model name      : ARMv7 Processor rev 1 (v7l)
> BogoMIPS        : 1594.16
> Features        : half thumb fastmult edsp tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x4
> CPU part        : 0xc09
> CPU revision    : 1
> 
> Hardware        : NPCMX50 Chip family
> Revision        : 0000
> Serial          : 0000000000000000
> 
> Go-redfish was checked out per the readme on
> https://github.com/superchalupa/go-redfish and built like this:
> 
> $ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh
> 
> Using the 'openssl' based HTTPS support because it's faster on 32-bit ARM.
> For x86 and 64-bit ARM, go native SSL is almost equal in performance. Read
> the readme for details.
> 
> I use a benchmark tool called 'hey': https://github.com/rakyll/hey, it is a load
> generator. You can install it like this: "go get github.com/rakyll/hey". It will
> put 'hey' in $GOPATH/bin/. The go-redfish server supports the redfish
> standard X-Auth-Token as well as Basic auth. The benchmarks below are
> using basic auth in the interest of brevity, but it's also simple to benchmark
> tokens. The numbers don't appear much different.
> 
> Here is a run against the most complicated output currently implemented.
> This run is for 10 seconds, with the default concurrency of 50 parallel
> requests. The result is that the average request is 0.1588s and the server
> handles an average of 312 requests per second.
> 
> $ hey -z 10s
> https://Administrator:password@10.35.174.126:8443/redfish/v1/Chassis/A33
> /Thermal
> Summary:
>   Total:        10.1230 secs
>   Slowest:      1.9524 secs
>   Fastest:      0.0051 secs
>   Average:      0.1588 secs
>   Requests/sec: 312.8521
> 
> Response time histogram:
>   0.005 [1]     |
>   0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
>   0.395 [31]    |
>   0.589 [5]     |
>   0.784 [9]     |
>   0.979 [10]    |
>   1.173 [9]     |
>   1.368 [8]     |
>   1.563 [5]     |
>   1.758 [2]     |
>   1.952 [25]    |
> 
> Latency distribution:
>   10% in 0.0840 secs
>   25% in 0.1159 secs
>   50% in 0.1374 secs
>   75% in 0.1576 secs
>   90% in 0.1748 secs
>   95% in 0.1874 secs
>   99% in 1.3962 secs
> 
> Details (average, fastest, slowest):
>   DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs
>   DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs
>   req write:     0.0000 secs, 0.0000 secs, 0.0007 secs
>   resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs
>   resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs
> 
> Status code distribution:
>   [200] 3167 responses
> 
> 
> The memory usage of the program under load (Resident size, IOW, RAM
> usage during load is roughly 16MB):
> 
> # cat /proc/$(pidof ocp-server.arm)/status
> Name:   ocp-server.arm
> Umask:  0022
> State:  S (sleeping)
> Tgid:   2737
> Ngid:   0
> Pid:    2737
> PPid:   2710
> TracerPid:      0
> Uid:    0       0       0       0
> Gid:    0       0       0       0
> FDSize: 256
> Groups: 0
> VmPeak:  1167212 kB
> VmSize:  1167212 kB
> VmLck:         0 kB
> VmPin:         0 kB
> VmHWM:     16924 kB
> VmRSS:     16844 kB
> RssAnon:            9200 kB
> RssFile:            1788 kB
> RssShmem:           5856 kB
> VmData:   395108 kB
> VmStk:       136 kB
> VmExe:      6304 kB
> VmLib:      2792 kB
> VmPTE:       130 kB
> VmPMD:         0 kB
> VmSwap:        0 kB
> Threads:        45
> SigQ:   0/3577
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: fffffffe7bfa7a25
> SigIgn: 0000000000000000
> SigCgt: ffffffffffc1feff
> CapInh: 0000000000000000
> CapPrm: 0000003fffffffff
> CapEff: 0000003fffffffff
> CapBnd: 0000003fffffffff
> CapAmb: 0000000000000000
> NoNewPrivs:     0
> Cpus_allowed:   3
> Cpus_allowed_list:      0-1
> voluntary_ctxt_switches:        92
> nonvoluntary_ctxt_switches:     21
> 
> The binary size is 10MB uncompressed and 2MB compressed (xz level 9)
> 
> $ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz $ ls -l ocp-server.arm* -
> rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052 Feb 14 13:14 ocp-
> server.arm
> -rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26 ocp-
> server.arm.xz
> 
> The source is currently sitting at under 5k LoC implementing a few proof of
> concept openbmc implementations calling DBUS, as well as a simulation.
> 
> Concurrency:
> - Highly concurrent. On ARM serves >300 requests per second. On X86, goes
> up to about 3k requests per second
> - For individual requests: can concurrently get data from multiple data
> sources and runs all the plugins for a redfish resource in parallel
> 
> Deterministic:
> - The design should be fairly deterministic.
> 
> Cached:
> - Completely flexible here. The default model is caching the data, but it's also
> supported to make dbus calls per request (though that's not really
> recommended). Currently it caches sensor results and refreshes those at a
> fixed interval, though that could easily be changed.
> 
> Platform dependent/independent:
> - Core is completely platform independent.
> - Working on an OCP profile implementation that also has platform
> independent + platform specific hooks. Currently in place are simulation
> implementation plus openbmc dbus implementation for sensors
> (temperature now, working fans next).
> 
> DMTF support:
> - In progress. Help needed.
> 
> --
> Michael
> 
> On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:
> > Here are some more requirements based on our experience with Redfish:
> > 1. Concurrency
> > Web Server and Framework should be able to serve multiple GET requests
> at a time.
> > POST/PATCH/PUT/DELETE requests can be sequential.
> >
> > 2. Deterministic
> > Service should be time deterministic, both boot time and run time.
> > Concurrency shall not impact deterministic property of the service.
> > All requests shall be responded (success/failure) within acceptable time
> limits.
> > Where some requests cannot be completed within time limits, service
> > shall respond with status and expected time to complete.
> >
> > 3. Cached Data
> > Data shall be cached by Redfish service and updated on dbus signals.
> > Collecting required information on demand adversely impacts
> performance.
> > Redfish should rather cache the information and keep updating its
> > cache on notification from dbus that the property(ies) of interest has been
> modified.
> >
> > 4. Platform dependent/independent layer Shall provide a clear
> > isolation between core vs platform properties.
> > Can consider object oriented approach for platform & oem layer to
> > override core methods and objects. Customized hooks and handlers can
> > be provided by platform layer while the data model between layers is
> > maintained consistent across platforms.
> >
> > 5. DMTF Support
> > Redfish have quite a lot of gaps in some of the basic requirements of a
> BMC.
> > a) FRU & FRU Collection Schema
> > b) Sensor & Sensor Collection Schema
> > c) Component Firmware Update (PSU, BIOS, CPLD, etc)
> > d) Master Write-Read
> > e) Clear PSU Faults
> > We need DMTF to actively add/update Redfish schemas that are
> fundamental to any BMC.
> >
> > 7. Error Codes
> > Redfish LogEntry schema doesn’t offer a placeholder for error codes
> > that automation tools can read to categorize the events and trigger
> actuators.
> > One option is to repurpose OEM field.
> >
> > 8. Pagination
> > Event logs can get too big and paginated view is helpful
> >
> > 9. Filtering
> > Query parameter to filter the response limited to certain criteria
> >
> > 10. Anchors
> > Schemas like Chassis and Manager have a bunch of properties that not
> > all requests might be interested in.
> > It is better to be able to request just a fragment of a resource using ‘#’.
> >
> > 11. Rate Limiting
> > Server shall return HTTP 429 when number of requests cross max limit
> permissible from a client.
> > We need some protection against Denial of Service.
> >
> > -Yugi

RE: Redfish on OpenBMC

[Ali Larijani]

Thanks Ed, your agenda looks very good to me.
If it works for everybody, let's schedule a meeting on Monday 2/26 next week at 2pm PST as a kick-off, and we can discuss time/frequency, agenda, etc...during that meeting.

Regards,
Ali

-----Original Message-----
From: Tanous, Ed <ed.tanous@intel.com> 
Sent: Thursday, February 22, 2018 2:31 PM
To: Michael.E.Brown@dell.com; Ali Larijani <alirhas@microsoft.com>; Yugi Mani <yupalani@microsoft.com>
Cc: Paul.Vancil@dell.com; hramasub@in.ibm.com; Balaji.B.Rao@dell.com; bradleyb@fuzziesquirrel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong <Chris.Ong@microsoft.com>
Subject: RE: Redfish on OpenBMC

Hah, you guys beat me to it.

My preference would be Monday at 4pm CST, 2PM PST, but I think I can make any of them that aren't Wednesday.

Also, If I'm reading this correct, this email only went out to a few of us.  Once we have a time, we should post it to the main email list as well.
I'm also happy to host if Michael can't.  BlueJeans seemed to work quite well for the TSC meetings, so I was thinking of doing that for sharing.


 Here was the email I was typing up yesterday:

I’d like to start a Redfish working group for OpenBMC.

Primary goals of this working group will be:
1.	Disseminate information on various redfish implementations for OpenBMC
2.	Discuss technical requirements and implementation specifics
3.	Make an effort to consolidate work on a “phosphor” OpenBMC redfish implementation

Initial Agenda for the first meeting will be

Initial introductions
Overview of existing implementations and work
	Bmcweb implementation by Intel – Ed Tanous
	Go-redfish implementation by Dell – Michael Brown
	Redfish implementation by Microsoft – Ali Larijani/Yugi Mani/Bryan Kelly
	Others?

Meeting time and frequency.
	Daily/Weekly/monthly/quarterly?
	What times work for the most people?

Consolidated requirements
	Do we want/need them?
	How will we handle them?
	How will we discuss architectural changes?

Language choice
	Python/C++/Golang preferences?

Other Topics?

> -----Original Message-----
> From: Michael.E.Brown@dell.com [mailto:Michael.E.Brown@dell.com]
> Sent: Thursday, February 22, 2018 2:03 PM
> To: alirhas@microsoft.com; yupalani@microsoft.com
> Cc: Paul.Vancil@dell.com; hramasub@in.ibm.com; Balaji.B.Rao@dell.com; 
> bradleyb@fuzziesquirrel.com; Tanous, Ed <ed.tanous@intel.com>; 
> jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; 
> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris.Ong@microsoft.com
> Subject: RE: Redfish on OpenBMC
> 
> Yes, I think it would be valuable to have a call. Do you have a time 
> proposal? I can host from Dell skype.
> 
> Proposed time slots. Here are a variety that personally work ok for me.
> Votes?
> 	Monday 4pm CST
> 	Wed evening 9pm CST
> 	Thursday morning 9am CST
> 	Thursday 12pm CST
> 	Friday 8am CST
> --
> Michael
> 
> -----Original Message-----
> From: Ali Larijani [mailto:alirhas@microsoft.com]
> Sent: Thursday, February 22, 2018 3:54 PM
> To: Brown, Michael E <Michael_E_Brown@Dell.com>; Yugi Mani 
> <yupalani@microsoft.com>
> Cc: Vancil, Paul <Paul_Vancil@Dell.com>; hramasub@in.ibm.com; Rao, 
> Balaji B <Balaji_B_Rao@dell.com>; bradleyb@fuzziesquirrel.com; 
> ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org; 
> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong 
> <Chris.Ong@microsoft.com>
> Subject: RE: Redfish on OpenBMC
> 
> Hi everybody,
> Can I propose we get together on a call to discuss a  plan moving 
> forward with Redfish implementation?
> Do you see any value of having a weekly sync up call?
> 
> Thanks
> Ali
> -----Original Message-----
> From: Michael E Brown <Michael.E.Brown@dell.com>
> Sent: Wednesday, February 14, 2018 11:37 AM
> To: Yugi Mani <yupalani@microsoft.com>
> Cc: Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com; 
> hramasub@in.ibm.com; Michael.E.Brown@dell.com; Balaji.B.Rao@dell.com; 
> bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com; 
> openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; 
> Chris Ong <Chris.Ong@microsoft.com>
> Subject: Re: Redfish on OpenBMC
> 
> Stats for go-redfish running on Nuvoton Poleg. First, processor stats. 
> Since we agreed on AST2500 as the baseline, I don't have one of those 
> to do benchmarks. If somebody could run the benchmarks on an AST2500 
> that would be very helpful.
> 
> $ cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 1 (v7l)
> BogoMIPS        : 1594.16
> Features        : half thumb fastmult edsp tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x4
> CPU part        : 0xc09
> CPU revision    : 1
> 
> processor       : 1
> model name      : ARMv7 Processor rev 1 (v7l)
> BogoMIPS        : 1594.16
> Features        : half thumb fastmult edsp tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x4
> CPU part        : 0xc09
> CPU revision    : 1
> 
> Hardware        : NPCMX50 Chip family
> Revision        : 0000
> Serial          : 0000000000000000
> 
> Go-redfish was checked out per the readme on 
> https://github.com/superchalupa/go-redfish and built like this:
> 
> $ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh
> 
> Using the 'openssl' based HTTPS support because it's faster on 32-bit ARM.
> For x86 and 64-bit ARM, go native SSL is almost equal in performance. 
> Read the readme for details.
> 
> I use a benchmark tool called 'hey': https://github.com/rakyll/hey, it 
> is a load generator. You can install it like this: "go get 
> github.com/rakyll/hey". It will put 'hey' in $GOPATH/bin/. The 
> go-redfish server supports the redfish standard X-Auth-Token as well 
> as Basic auth. The benchmarks below are using basic auth in the 
> interest of brevity, but it's also simple to benchmark tokens. The numbers don't appear much different.
> 
> Here is a run against the most complicated output currently implemented.
> This run is for 10 seconds, with the default concurrency of 50 
> parallel requests. The result is that the average request is 0.1588s 
> and the server handles an average of 312 requests per second.
> 
> $ hey -z 10s
> https://Administrator:password@10.35.174.126:8443/redfish/v1/Chassis/A
> 33
> /Thermal
> Summary:
>   Total:        10.1230 secs
>   Slowest:      1.9524 secs
>   Fastest:      0.0051 secs
>   Average:      0.1588 secs
>   Requests/sec: 312.8521
> 
> Response time histogram:
>   0.005 [1]     |
>   0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
>   0.395 [31]    |
>   0.589 [5]     |
>   0.784 [9]     |
>   0.979 [10]    |
>   1.173 [9]     |
>   1.368 [8]     |
>   1.563 [5]     |
>   1.758 [2]     |
>   1.952 [25]    |
> 
> Latency distribution:
>   10% in 0.0840 secs
>   25% in 0.1159 secs
>   50% in 0.1374 secs
>   75% in 0.1576 secs
>   90% in 0.1748 secs
>   95% in 0.1874 secs
>   99% in 1.3962 secs
> 
> Details (average, fastest, slowest):
>   DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs
>   DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs
>   req write:     0.0000 secs, 0.0000 secs, 0.0007 secs
>   resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs
>   resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs
> 
> Status code distribution:
>   [200] 3167 responses
> 
> 
> The memory usage of the program under load (Resident size, IOW, RAM 
> usage during load is roughly 16MB):
> 
> # cat /proc/$(pidof ocp-server.arm)/status
> Name:   ocp-server.arm
> Umask:  0022
> State:  S (sleeping)
> Tgid:   2737
> Ngid:   0
> Pid:    2737
> PPid:   2710
> TracerPid:      0
> Uid:    0       0       0       0
> Gid:    0       0       0       0
> FDSize: 256
> Groups: 0
> VmPeak:  1167212 kB
> VmSize:  1167212 kB
> VmLck:         0 kB
> VmPin:         0 kB
> VmHWM:     16924 kB
> VmRSS:     16844 kB
> RssAnon:            9200 kB
> RssFile:            1788 kB
> RssShmem:           5856 kB
> VmData:   395108 kB
> VmStk:       136 kB
> VmExe:      6304 kB
> VmLib:      2792 kB
> VmPTE:       130 kB
> VmPMD:         0 kB
> VmSwap:        0 kB
> Threads:        45
> SigQ:   0/3577
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: fffffffe7bfa7a25
> SigIgn: 0000000000000000
> SigCgt: ffffffffffc1feff
> CapInh: 0000000000000000
> CapPrm: 0000003fffffffff
> CapEff: 0000003fffffffff
> CapBnd: 0000003fffffffff
> CapAmb: 0000000000000000
> NoNewPrivs:     0
> Cpus_allowed:   3
> Cpus_allowed_list:      0-1
> voluntary_ctxt_switches:        92
> nonvoluntary_ctxt_switches:     21
> 
> The binary size is 10MB uncompressed and 2MB compressed (xz level 9)
> 
> $ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz $ ls -l 
> ocp-server.arm* - rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052 
> Feb 14 13:14 ocp- server.arm
> -rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26 
> ocp- server.arm.xz
> 
> The source is currently sitting at under 5k LoC implementing a few 
> proof of concept openbmc implementations calling DBUS, as well as a simulation.
> 
> Concurrency:
> - Highly concurrent. On ARM serves >300 requests per second. On X86, 
> goes up to about 3k requests per second
> - For individual requests: can concurrently get data from multiple 
> data sources and runs all the plugins for a redfish resource in 
> parallel
> 
> Deterministic:
> - The design should be fairly deterministic.
> 
> Cached:
> - Completely flexible here. The default model is caching the data, but 
> it's also supported to make dbus calls per request (though that's not 
> really recommended). Currently it caches sensor results and refreshes 
> those at a fixed interval, though that could easily be changed.
> 
> Platform dependent/independent:
> - Core is completely platform independent.
> - Working on an OCP profile implementation that also has platform 
> independent + platform specific hooks. Currently in place are 
> simulation implementation plus openbmc dbus implementation for sensors 
> (temperature now, working fans next).
> 
> DMTF support:
> - In progress. Help needed.
> 
> --
> Michael
> 
> On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:
> > Here are some more requirements based on our experience with Redfish:
> > 1. Concurrency
> > Web Server and Framework should be able to serve multiple GET 
> > requests
> at a time.
> > POST/PATCH/PUT/DELETE requests can be sequential.
> >
> > 2. Deterministic
> > Service should be time deterministic, both boot time and run time.
> > Concurrency shall not impact deterministic property of the service.
> > All requests shall be responded (success/failure) within acceptable 
> > time
> limits.
> > Where some requests cannot be completed within time limits, service 
> > shall respond with status and expected time to complete.
> >
> > 3. Cached Data
> > Data shall be cached by Redfish service and updated on dbus signals.
> > Collecting required information on demand adversely impacts
> performance.
> > Redfish should rather cache the information and keep updating its 
> > cache on notification from dbus that the property(ies) of interest 
> > has been
> modified.
> >
> > 4. Platform dependent/independent layer Shall provide a clear 
> > isolation between core vs platform properties.
> > Can consider object oriented approach for platform & oem layer to 
> > override core methods and objects. Customized hooks and handlers can 
> > be provided by platform layer while the data model between layers is 
> > maintained consistent across platforms.
> >
> > 5. DMTF Support
> > Redfish have quite a lot of gaps in some of the basic requirements 
> > of a
> BMC.
> > a) FRU & FRU Collection Schema
> > b) Sensor & Sensor Collection Schema
> > c) Component Firmware Update (PSU, BIOS, CPLD, etc)
> > d) Master Write-Read
> > e) Clear PSU Faults
> > We need DMTF to actively add/update Redfish schemas that are
> fundamental to any BMC.
> >
> > 7. Error Codes
> > Redfish LogEntry schema doesn’t offer a placeholder for error codes 
> > that automation tools can read to categorize the events and trigger
> actuators.
> > One option is to repurpose OEM field.
> >
> > 8. Pagination
> > Event logs can get too big and paginated view is helpful
> >
> > 9. Filtering
> > Query parameter to filter the response limited to certain criteria
> >
> > 10. Anchors
> > Schemas like Chassis and Manager have a bunch of properties that not 
> > all requests might be interested in.
> > It is better to be able to request just a fragment of a resource using ‘#’.
> >
> > 11. Rate Limiting
> > Server shall return HTTP 429 when number of requests cross max limit
> permissible from a client.
> > We need some protection against Denial of Service.
> >
> > -Yugi

RE: Redfish on OpenBMC

[Hariharasubramanian Ramasubramanian]

[-- Attachment #1.1: Type: text/plain, Size: 16076 bytes --]

Sound like we are ready for a take off :-)


2PM PST(1:30AM IST) is a little inconvenient. My votes are for the below
times:
      > 		 Wed evening 9pm CST
      > 		 Thursday morning 9am CST
      > 		 Friday 8am CST

Also BlueJeans is a paid offering. Zoom probably would suit us better if we
can limit our meetings to 40 mins.

Michael & me had an irc conversation earlier and my thoughts align with Ed.
My wishlist was:

      1) Targeted discussion with the contributors. (irc/webex/whatever
      else works).
      2) Setting up the wiki for documenting our discussions.
      3) Get the contributors code onto github and review
      4) A hackathon may be to "add a new resource" using each of the
      implementations.

regards,
Hari !



From:	Ali Larijani <alirhas@microsoft.com>
To:	"Tanous, Ed" <ed.tanous@intel.com>, "Michael.E.Brown@dell.com"
            <Michael.E.Brown@dell.com>, Yugi Mani <yupalani@microsoft.com>
Cc:	"Paul.Vancil@dell.com" <Paul.Vancil@dell.com>,
            "hramasub@in.ibm.com" <hramasub@in.ibm.com>,
            "Balaji.B.Rao@dell.com" <Balaji.B.Rao@dell.com>,
            "bradleyb@fuzziesquirrel.com" <bradleyb@fuzziesquirrel.com>,
            "jwcarman@us.ibm.com" <jwcarman@us.ibm.com>,
            "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
            "pradeep.kumar36@tcs.com" <pradeep.kumar36@tcs.com>,
            "rolfb@us.ibm.com" <rolfb@us.ibm.com>, Chris Ong
            <Chris.Ong@microsoft.com>
Date:	02/23/2018 08:19 AM
Subject:	RE: Redfish on OpenBMC



Thanks Ed, your agenda looks very good to me.

If it works for everybody, let's schedule a meeting on Monday 2/26 next
week at 2pm PST as a kick-off, and we can discuss time/frequency, agenda,
etc...during that meeting.



Regards,

Ali



-----Original Message-----

From: Tanous, Ed <ed.tanous@intel.com>

Sent: Thursday, February 22, 2018 2:31 PM

To: Michael.E.Brown@dell.com; Ali Larijani <alirhas@microsoft.com>; Yugi
Mani <yupalani@microsoft.com>

Cc: Paul.Vancil@dell.com; hramasub@in.ibm.com; Balaji.B.Rao@dell.com;
bradleyb@fuzziesquirrel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org;
pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong
<Chris.Ong@microsoft.com>

Subject: RE: Redfish on OpenBMC



Hah, you guys beat me to it.



My preference would be Monday at 4pm CST, 2PM PST, but I think I can make
any of them that aren't Wednesday.



Also, If I'm reading this correct, this email only went out to a few of us.
Once we have a time, we should post it to the main email list as well.

I'm also happy to host if Michael can't.  BlueJeans seemed to work quite
well for the TSC meetings, so I was thinking of doing that for sharing.





 Here was the email I was typing up yesterday:



I’d like to start a Redfish working group for OpenBMC.



Primary goals of this working group will be:

1.		 Disseminate information on various redfish implementations for
OpenBMC

2.		 Discuss technical requirements and implementation specifics

3.		 Make an effort to consolidate work on a “phosphor” OpenBMC
redfish implementation



Initial Agenda for the first meeting will be



Initial introductions

Overview of existing implementations and work

		 Bmcweb implementation by Intel – Ed Tanous

		 Go-redfish implementation by Dell – Michael Brown

		 Redfish implementation by Microsoft – Ali Larijani/Yugi
Mani/Bryan Kelly

		 Others?



Meeting time and frequency.

		 Daily/Weekly/monthly/quarterly?

		 What times work for the most people?



Consolidated requirements

		 Do we want/need them?

		 How will we handle them?

		 How will we discuss architectural changes?



Language choice

		 Python/C++/Golang preferences?



Other Topics?



> -----Original Message-----

> From: Michael.E.Brown@dell.com [mailto:Michael.E.Brown@dell.com]

> Sent: Thursday, February 22, 2018 2:03 PM

> To: alirhas@microsoft.com; yupalani@microsoft.com

> Cc: Paul.Vancil@dell.com; hramasub@in.ibm.com; Balaji.B.Rao@dell.com;

> bradleyb@fuzziesquirrel.com; Tanous, Ed <ed.tanous@intel.com>;

> jwcarman@us.ibm.com; openbmc@lists.ozlabs.org;

> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris.Ong@microsoft.com

> Subject: RE: Redfish on OpenBMC

>

> Yes, I think it would be valuable to have a call. Do you have a time

> proposal? I can host from Dell skype.

>

> Proposed time slots. Here are a variety that personally work ok for me.

> Votes?

> 		 Monday 4pm CST

> 		 Wed evening 9pm CST

> 		 Thursday morning 9am CST

> 		 Thursday 12pm CST

> 		 Friday 8am CST

> --

> Michael

>

> -----Original Message-----

> From: Ali Larijani [mailto:alirhas@microsoft.com]

> Sent: Thursday, February 22, 2018 3:54 PM

> To: Brown, Michael E <Michael_E_Brown@Dell.com>; Yugi Mani

> <yupalani@microsoft.com>

> Cc: Vancil, Paul <Paul_Vancil@Dell.com>; hramasub@in.ibm.com; Rao,

> Balaji B <Balaji_B_Rao@dell.com>; bradleyb@fuzziesquirrel.com;

> ed.tanous@intel.com; jwcarman@us.ibm.com; openbmc@lists.ozlabs.org;

> pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Chris Ong

> <Chris.Ong@microsoft.com>

> Subject: RE: Redfish on OpenBMC

>

> Hi everybody,

> Can I propose we get together on a call to discuss a  plan moving

> forward with Redfish implementation?

> Do you see any value of having a weekly sync up call?

>

> Thanks

> Ali

> -----Original Message-----

> From: Michael E Brown <Michael.E.Brown@dell.com>

> Sent: Wednesday, February 14, 2018 11:37 AM

> To: Yugi Mani <yupalani@microsoft.com>

> Cc: Ali Larijani <alirhas@microsoft.com>; Paul.Vancil@dell.com;

> hramasub@in.ibm.com; Michael.E.Brown@dell.com; Balaji.B.Rao@dell.com;

> bradleyb@fuzziesquirrel.com; ed.tanous@intel.com; jwcarman@us.ibm.com;

> openbmc@lists.ozlabs.org; pradeep.kumar36@tcs.com; rolfb@us.ibm.com;

> Chris Ong <Chris.Ong@microsoft.com>

> Subject: Re: Redfish on OpenBMC

>

> Stats for go-redfish running on Nuvoton Poleg. First, processor stats.

> Since we agreed on AST2500 as the baseline, I don't have one of those

> to do benchmarks. If somebody could run the benchmarks on an AST2500

> that would be very helpful.

>

> $ cat /proc/cpuinfo

> processor       : 0

> model name      : ARMv7 Processor rev 1 (v7l)

> BogoMIPS        : 1594.16

> Features        : half thumb fastmult edsp tls

> CPU implementer : 0x41

> CPU architecture: 7

> CPU variant     : 0x4

> CPU part        : 0xc09

> CPU revision    : 1

>

> processor       : 1

> model name      : ARMv7 Processor rev 1 (v7l)

> BogoMIPS        : 1594.16

> Features        : half thumb fastmult edsp tls

> CPU implementer : 0x41

> CPU architecture: 7

> CPU variant     : 0x4

> CPU part        : 0xc09

> CPU revision    : 1

>

> Hardware        : NPCMX50 Chip family

> Revision        : 0000

> Serial          : 0000000000000000

>

> Go-redfish was checked out per the readme on

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_superchalupa_go-2Dredfish&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=0V5mbubQ_XiZn1wp-lyxRsX_oDp_ZU7L7TB3taw6jnY&s=Jx5_QlMbwpuLrpxlue61p7uHJvoIZLLO-UiRz_Eohlk&e=
 and built like this:

>

> $ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh

>

> Using the 'openssl' based HTTPS support because it's faster on 32-bit
ARM.

> For x86 and 64-bit ARM, go native SSL is almost equal in performance.

> Read the readme for details.

>

> I use a benchmark tool called 'hey':
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rakyll_hey&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=0V5mbubQ_XiZn1wp-lyxRsX_oDp_ZU7L7TB3taw6jnY&s=rj8l_-oJwvoZhuKeQBtdNhHF22_w46dLHGS5Dgwi1Pk&e=
, it

> is a load generator. You can install it like this: "go get

> github.com/rakyll/hey". It will put 'hey' in $GOPATH/bin/. The

> go-redfish server supports the redfish standard X-Auth-Token as well

> as Basic auth. The benchmarks below are using basic auth in the

> interest of brevity, but it's also simple to benchmark tokens. The
numbers don't appear much different.

>

> Here is a run against the most complicated output currently implemented.

> This run is for 10 seconds, with the default concurrency of 50

> parallel requests. The result is that the average request is 0.1588s

> and the server handles an average of 312 requests per second.

>

> $ hey -z 10s

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__Administrator-3Apassword-4010.35.174.126-3A8443_redfish_v1_Chassis_A&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=0V5mbubQ_XiZn1wp-lyxRsX_oDp_ZU7L7TB3taw6jnY&s=39htxfH8ZCgtnHsY85iUfsJYfVNHk5Hy1w0u3N6S73s&e=


> 33

> /Thermal

> Summary:

>   Total:        10.1230 secs

>   Slowest:      1.9524 secs

>   Fastest:      0.0051 secs

>   Average:      0.1588 secs

>   Requests/sec: 312.8521

>

> Response time histogram:

>   0.005 [1]     |

>   0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎

>   0.395 [31]    |

>   0.589 [5]     |

>   0.784 [9]     |

>   0.979 [10]    |

>   1.173 [9]     |

>   1.368 [8]     |

>   1.563 [5]     |

>   1.758 [2]     |

>   1.952 [25]    |

>

> Latency distribution:

>   10% in 0.0840 secs

>   25% in 0.1159 secs

>   50% in 0.1374 secs

>   75% in 0.1576 secs

>   90% in 0.1748 secs

>   95% in 0.1874 secs

>   99% in 1.3962 secs

>

> Details (average, fastest, slowest):

>   DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs

>   DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs

>   req write:     0.0000 secs, 0.0000 secs, 0.0007 secs

>   resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs

>   resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs

>

> Status code distribution:

>   [200] 3167 responses

>

>

> The memory usage of the program under load (Resident size, IOW, RAM

> usage during load is roughly 16MB):

>

> # cat /proc/$(pidof ocp-server.arm)/status

> Name:   ocp-server.arm

> Umask:  0022

> State:  S (sleeping)

> Tgid:   2737

> Ngid:   0

> Pid:    2737

> PPid:   2710

> TracerPid:      0

> Uid:    0       0       0       0

> Gid:    0       0       0       0

> FDSize: 256

> Groups: 0

> VmPeak:  1167212 kB

> VmSize:  1167212 kB

> VmLck:         0 kB

> VmPin:         0 kB

> VmHWM:     16924 kB

> VmRSS:     16844 kB

> RssAnon:            9200 kB

> RssFile:            1788 kB

> RssShmem:           5856 kB

> VmData:   395108 kB

> VmStk:       136 kB

> VmExe:      6304 kB

> VmLib:      2792 kB

> VmPTE:       130 kB

> VmPMD:         0 kB

> VmSwap:        0 kB

> Threads:        45

> SigQ:   0/3577

> SigPnd: 0000000000000000

> ShdPnd: 0000000000000000

> SigBlk: fffffffe7bfa7a25

> SigIgn: 0000000000000000

> SigCgt: ffffffffffc1feff

> CapInh: 0000000000000000

> CapPrm: 0000003fffffffff

> CapEff: 0000003fffffffff

> CapBnd: 0000003fffffffff

> CapAmb: 0000000000000000

> NoNewPrivs:     0

> Cpus_allowed:   3

> Cpus_allowed_list:      0-1

> voluntary_ctxt_switches:        92

> nonvoluntary_ctxt_switches:     21

>

> The binary size is 10MB uncompressed and 2MB compressed (xz level 9)

>

> $ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz $ ls -l

> ocp-server.arm* - rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052

> Feb 14 13:14 ocp- server.arm

> -rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26

> ocp- server.arm.xz

>

> The source is currently sitting at under 5k LoC implementing a few

> proof of concept openbmc implementations calling DBUS, as well as a
simulation.

>

> Concurrency:

> - Highly concurrent. On ARM serves >300 requests per second. On X86,

> goes up to about 3k requests per second

> - For individual requests: can concurrently get data from multiple

> data sources and runs all the plugins for a redfish resource in

> parallel

>

> Deterministic:

> - The design should be fairly deterministic.

>

> Cached:

> - Completely flexible here. The default model is caching the data, but

> it's also supported to make dbus calls per request (though that's not

> really recommended). Currently it caches sensor results and refreshes

> those at a fixed interval, though that could easily be changed.

>

> Platform dependent/independent:

> - Core is completely platform independent.

> - Working on an OCP profile implementation that also has platform

> independent + platform specific hooks. Currently in place are

> simulation implementation plus openbmc dbus implementation for sensors

> (temperature now, working fans next).

>

> DMTF support:

> - In progress. Help needed.

>

> --

> Michael

>

> On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:

> > Here are some more requirements based on our experience with Redfish:

> > 1. Concurrency

> > Web Server and Framework should be able to serve multiple GET

> > requests

> at a time.

> > POST/PATCH/PUT/DELETE requests can be sequential.

> >

> > 2. Deterministic

> > Service should be time deterministic, both boot time and run time.

> > Concurrency shall not impact deterministic property of the service.

> > All requests shall be responded (success/failure) within acceptable

> > time

> limits.

> > Where some requests cannot be completed within time limits, service

> > shall respond with status and expected time to complete.

> >

> > 3. Cached Data

> > Data shall be cached by Redfish service and updated on dbus signals.

> > Collecting required information on demand adversely impacts

> performance.

> > Redfish should rather cache the information and keep updating its

> > cache on notification from dbus that the property(ies) of interest

> > has been

> modified.

> >

> > 4. Platform dependent/independent layer Shall provide a clear

> > isolation between core vs platform properties.

> > Can consider object oriented approach for platform & oem layer to

> > override core methods and objects. Customized hooks and handlers can

> > be provided by platform layer while the data model between layers is

> > maintained consistent across platforms.

> >

> > 5. DMTF Support

> > Redfish have quite a lot of gaps in some of the basic requirements

> > of a

> BMC.

> > a) FRU & FRU Collection Schema

> > b) Sensor & Sensor Collection Schema

> > c) Component Firmware Update (PSU, BIOS, CPLD, etc)

> > d) Master Write-Read

> > e) Clear PSU Faults

> > We need DMTF to actively add/update Redfish schemas that are

> fundamental to any BMC.

> >

> > 7. Error Codes

> > Redfish LogEntry schema doesn’t offer a placeholder for error codes

> > that automation tools can read to categorize the events and trigger

> actuators.

> > One option is to repurpose OEM field.

> >

> > 8. Pagination

> > Event logs can get too big and paginated view is helpful

> >

> > 9. Filtering

> > Query parameter to filter the response limited to certain criteria

> >

> > 10. Anchors

> > Schemas like Chassis and Manager have a bunch of properties that not

> > all requests might be interested in.

> > It is better to be able to request just a fragment of a resource using
‘#’.

> >

> > 11. Rate Limiting

> > Server shall return HTTP 429 when number of requests cross max limit

> permissible from a client.

> > We need some protection against Denial of Service.

> >

> > -Yugi





[-- Attachment #1.2: Type: text/html, Size: 22876 bytes --]

[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Paul.Vancil]

[-- Attachment #1.1: Type: text/plain, Size: 20173 bytes --]

Michael,
I can meet any of the times you proposed.     ( I have a conflict 2-3 CST on Monday but you didn’t propose that).
To the list of Implementations to look at:
  Overview of existing implementations and work
    Bmcweb implementation by Intel – Ed Tanous
    Go-redfish implementation by Dell – Michael Brown
    Redfish implementation by Microsoft – Ali Larijani/Yugi Mani/Bryan Kelly
Please add:
          RedDrum python implementation by Dell  -- Paul Vancil/Balaji B Rao
                --We have this open sourced now on github. At:  github.com/RedDrum-Redfish-Project
                   --there is both a Simulator backend and an OpenBMC backend
                   --Balaji is finishing the Yocto recipes to build it into an image now
                   --we have it running on a Power9 board with most of the HW interfaces integrated
                   --we will have this setup as a demo at OCP (the Simulator and the Power9 openBMC)
                --we will update the measurements on performance and size next week, but we have some earlier measurements if we need to share on Mon.
                -- this is python which has some advantages in some cases buy not probably the best for some.

Thanks,
Paul Vancil

From: Hariharasubramanian Ramasubramanian [mailto:hramasub@in.ibm.com]
Sent: Thursday, February 22, 2018 9:16 PM
To: Ali Larijani <alirhas@microsoft.com>
Cc: Rao, Balaji B <Balaji_B_Rao@dell.com>; bradleyb@fuzziesquirrel.com; Chris Ong <Chris.Ong@microsoft.com>; Tanous, Ed <ed.tanous@intel.com>; jwcarman@us.ibm.com; Brown, Michael E <Michael_E_Brown@Dell.com>; openbmc@lists.ozlabs.org; Vancil, Paul <Paul_Vancil@Dell.com>; pradeep.kumar36@tcs.com; rolfb@us.ibm.com; Yugi Mani <yupalani@microsoft.com>
Subject: RE: Redfish on OpenBMC


Sound like we are ready for a take off :-)


2PM PST(1:30AM IST) is a little inconvenient. My votes are for the below times:
> Wed evening 9pm CST
> Thursday morning 9am CST
> Friday 8am CST

Also BlueJeans is a paid offering. Zoom probably would suit us better if we can limit our meetings to 40 mins.

Michael & me had an irc conversation earlier and my thoughts align with Ed. My wishlist was:
1) Targeted discussion with the contributors. (irc/webex/whatever else works).
2) Setting up the wiki for documenting our discussions.
3) Get the contributors code onto github and review
4) A hackathon may be to "add a new resource" using each of the implementations.

regards,
Hari !

[Inactive hide details for Ali Larijani ---02/23/2018 08:19:20 AM---Thanks Ed, your agenda looks very good to me. If it works fo]Ali Larijani ---02/23/2018 08:19:20 AM---Thanks Ed, your agenda looks very good to me. If it works for everybody, let's schedule a meeting on

From: Ali Larijani <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>
To: "Tanous, Ed" <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>, "Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>" <Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>>, Yugi Mani <yupalani@microsoft.com<mailto:yupalani@microsoft.com>>
Cc: "Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>" <Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>>, "hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>" <hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>>, "Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>" <Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>>, "bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>" <bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>>, "jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>" <jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>>, "openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>" <openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>>, "pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>" <pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>>, "rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>" <rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>>, Chris Ong <Chris.Ong@microsoft.com<mailto:Chris.Ong@microsoft.com>>
Date: 02/23/2018 08:19 AM
Subject: RE: Redfish on OpenBMC
________________________________



Thanks Ed, your agenda looks very good to me.

If it works for everybody, let's schedule a meeting on Monday 2/26 next week at 2pm PST as a kick-off, and we can discuss time/frequency, agenda, etc...during that meeting.



Regards,

Ali



-----Original Message-----

From: Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>

Sent: Thursday, February 22, 2018 2:31 PM

To: Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>; Ali Larijani <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>; Yugi Mani <yupalani@microsoft.com<mailto:yupalani@microsoft.com>>

Cc: Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>; hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>; Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>; bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; Chris Ong <Chris.Ong@microsoft.com<mailto:Chris.Ong@microsoft.com>>

Subject: RE: Redfish on OpenBMC



Hah, you guys beat me to it.



My preference would be Monday at 4pm CST, 2PM PST, but I think I can make any of them that aren't Wednesday.



Also, If I'm reading this correct, this email only went out to a few of us.  Once we have a time, we should post it to the main email list as well.

I'm also happy to host if Michael can't.  BlueJeans seemed to work quite well for the TSC meetings, so I was thinking of doing that for sharing.





Here was the email I was typing up yesterday:



I’d like to start a Redfish working group for OpenBMC.



Primary goals of this working group will be:

1. Disseminate information on various redfish implementations for OpenBMC

2. Discuss technical requirements and implementation specifics

3. Make an effort to consolidate work on a “phosphor” OpenBMC redfish implementation



Initial Agenda for the first meeting will be



Initial introductions

Overview of existing implementations and work

Bmcweb implementation by Intel – Ed Tanous

Go-redfish implementation by Dell – Michael Brown

Redfish implementation by Microsoft – Ali Larijani/Yugi Mani/Bryan Kelly

Others?



Meeting time and frequency.

Daily/Weekly/monthly/quarterly?

What times work for the most people?



Consolidated requirements

Do we want/need them?

How will we handle them?

How will we discuss architectural changes?



Language choice

Python/C++/Golang preferences?



Other Topics?



> -----Original Message-----

> From: Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com> [mailto:Michael.E.Brown@dell.com]

> Sent: Thursday, February 22, 2018 2:03 PM

> To: alirhas@microsoft.com<mailto:alirhas@microsoft.com>; yupalani@microsoft.com<mailto:yupalani@microsoft.com>

> Cc: Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>; hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>; Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>;

> bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>; Tanous, Ed <ed.tanous@intel.com<mailto:ed.tanous@intel.com>>;

> jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>;

> pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; Chris.Ong@microsoft.com<mailto:Chris.Ong@microsoft.com>

> Subject: RE: Redfish on OpenBMC

>

> Yes, I think it would be valuable to have a call. Do you have a time

> proposal? I can host from Dell skype.

>

> Proposed time slots. Here are a variety that personally work ok for me.

> Votes?

> Monday 4pm CST

> Wed evening 9pm CST

> Thursday morning 9am CST

> Thursday 12pm CST

> Friday 8am CST

> --

> Michael

>

> -----Original Message-----

> From: Ali Larijani [mailto:alirhas@microsoft.com]

> Sent: Thursday, February 22, 2018 3:54 PM

> To: Brown, Michael E <Michael_E_Brown@Dell.com<mailto:Michael_E_Brown@Dell.com>>; Yugi Mani

> <yupalani@microsoft.com<mailto:yupalani@microsoft.com>>

> Cc: Vancil, Paul <Paul_Vancil@Dell.com<mailto:Paul_Vancil@Dell.com>>; hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>; Rao,

> Balaji B <Balaji_B_Rao@dell.com<mailto:Balaji_B_Rao@dell.com>>; bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>;

> ed.tanous@intel.com<mailto:ed.tanous@intel.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>; openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>;

> pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>; Chris Ong

> <Chris.Ong@microsoft.com<mailto:Chris.Ong@microsoft.com>>

> Subject: RE: Redfish on OpenBMC

>

> Hi everybody,

> Can I propose we get together on a call to discuss a  plan moving

> forward with Redfish implementation?

> Do you see any value of having a weekly sync up call?

>

> Thanks

> Ali

> -----Original Message-----

> From: Michael E Brown <Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>>

> Sent: Wednesday, February 14, 2018 11:37 AM

> To: Yugi Mani <yupalani@microsoft.com<mailto:yupalani@microsoft.com>>

> Cc: Ali Larijani <alirhas@microsoft.com<mailto:alirhas@microsoft.com>>; Paul.Vancil@dell.com<mailto:Paul.Vancil@dell.com>;

> hramasub@in.ibm.com<mailto:hramasub@in.ibm.com>; Michael.E.Brown@dell.com<mailto:Michael.E.Brown@dell.com>; Balaji.B.Rao@dell.com<mailto:Balaji.B.Rao@dell.com>;

> bradleyb@fuzziesquirrel.com<mailto:bradleyb@fuzziesquirrel.com>; ed.tanous@intel.com<mailto:ed.tanous@intel.com>; jwcarman@us.ibm.com<mailto:jwcarman@us.ibm.com>;

> openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>; pradeep.kumar36@tcs.com<mailto:pradeep.kumar36@tcs.com>; rolfb@us.ibm.com<mailto:rolfb@us.ibm.com>;

> Chris Ong <Chris.Ong@microsoft.com<mailto:Chris.Ong@microsoft.com>>

> Subject: Re: Redfish on OpenBMC

>

> Stats for go-redfish running on Nuvoton Poleg. First, processor stats.

> Since we agreed on AST2500 as the baseline, I don't have one of those

> to do benchmarks. If somebody could run the benchmarks on an AST2500

> that would be very helpful.

>

> $ cat /proc/cpuinfo

> processor       : 0

> model name      : ARMv7 Processor rev 1 (v7l)

> BogoMIPS        : 1594.16

> Features        : half thumb fastmult edsp tls

> CPU implementer : 0x41

> CPU architecture: 7

> CPU variant     : 0x4

> CPU part        : 0xc09

> CPU revision    : 1

>

> processor       : 1

> model name      : ARMv7 Processor rev 1 (v7l)

> BogoMIPS        : 1594.16

> Features        : half thumb fastmult edsp tls

> CPU implementer : 0x41

> CPU architecture: 7

> CPU variant     : 0x4

> CPU part        : 0xc09

> CPU revision    : 1

>

> Hardware        : NPCMX50 Chip family

> Revision        : 0000

> Serial          : 0000000000000000

>

> Go-redfish was checked out per the readme on

> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_superchalupa_go-2Dredfish&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=0V5mbubQ_XiZn1wp-lyxRsX_oDp_ZU7L7TB3taw6jnY&s=Jx5_QlMbwpuLrpxlue61p7uHJvoIZLLO-UiRz_Eohlk&e= and built like this:

>

> $ BUILD_TAGS="spacemonkey" ./scripts/build-arm-obmc.sh

>

> Using the 'openssl' based HTTPS support because it's faster on 32-bit ARM.

> For x86 and 64-bit ARM, go native SSL is almost equal in performance.

> Read the readme for details.

>

> I use a benchmark tool called 'hey': https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rakyll_hey&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=0V5mbubQ_XiZn1wp-lyxRsX_oDp_ZU7L7TB3taw6jnY&s=rj8l_-oJwvoZhuKeQBtdNhHF22_w46dLHGS5Dgwi1Pk&e=, it

> is a load generator. You can install it like this: "go get

> github.com/rakyll/hey". It will put 'hey' in $GOPATH/bin/. The

> go-redfish server supports the redfish standard X-Auth-Token as well

> as Basic auth. The benchmarks below are using basic auth in the

> interest of brevity, but it's also simple to benchmark tokens. The numbers don't appear much different.

>

> Here is a run against the most complicated output currently implemented.

> This run is for 10 seconds, with the default concurrency of 50

> parallel requests. The result is that the average request is 0.1588s

> and the server handles an average of 312 requests per second.

>

> $ hey -z 10s

> https://urldefense.proofpoint.com/v2/url?u=https-3A__Administrator-3Apassword-4010.35.174.126-3A8443_redfish_v1_Chassis_A&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pH43eFdHEcrwxCxoIddEpbqszBn5JkXE8WT1-pzfg5U&m=0V5mbubQ_XiZn1wp-lyxRsX_oDp_ZU7L7TB3taw6jnY&s=39htxfH8ZCgtnHsY85iUfsJYfVNHk5Hy1w0u3N6S73s&e=

> 33

> /Thermal

> Summary:

>   Total:        10.1230 secs

>   Slowest:      1.9524 secs

>   Fastest:      0.0051 secs

>   Average:      0.1588 secs

>   Requests/sec: 312.8521

>

> Response time histogram:

>   0.005 [1]     |

>   0.200 [3062]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎

>   0.395 [31]    |

>   0.589 [5]     |

>   0.784 [9]     |

>   0.979 [10]    |

>   1.173 [9]     |

>   1.368 [8]     |

>   1.563 [5]     |

>   1.758 [2]     |

>   1.952 [25]    |

>

> Latency distribution:

>   10% in 0.0840 secs

>   25% in 0.1159 secs

>   50% in 0.1374 secs

>   75% in 0.1576 secs

>   90% in 0.1748 secs

>   95% in 0.1874 secs

>   99% in 1.3962 secs

>

> Details (average, fastest, slowest):

>   DNS+dialup:    0.0036 secs, 0.0000 secs, 1.2168 secs

>   DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0000 secs

>   req write:     0.0000 secs, 0.0000 secs, 0.0007 secs

>   resp wait:     0.1411 secs, 0.0049 secs, 1.1510 secs

>   resp read:     0.0001 secs, 0.0000 secs, 0.0002 secs

>

> Status code distribution:

>   [200] 3167 responses

>

>

> The memory usage of the program under load (Resident size, IOW, RAM

> usage during load is roughly 16MB):

>

> # cat /proc/$(pidof ocp-server.arm)/status

> Name:   ocp-server.arm

> Umask:  0022

> State:  S (sleeping)

> Tgid:   2737

> Ngid:   0

> Pid:    2737

> PPid:   2710

> TracerPid:      0

> Uid:    0       0       0       0

> Gid:    0       0       0       0

> FDSize: 256

> Groups: 0

> VmPeak:  1167212 kB

> VmSize:  1167212 kB

> VmLck:         0 kB

> VmPin:         0 kB

> VmHWM:     16924 kB

> VmRSS:     16844 kB

> RssAnon:            9200 kB

> RssFile:            1788 kB

> RssShmem:           5856 kB

> VmData:   395108 kB

> VmStk:       136 kB

> VmExe:      6304 kB

> VmLib:      2792 kB

> VmPTE:       130 kB

> VmPMD:         0 kB

> VmSwap:        0 kB

> Threads:        45

> SigQ:   0/3577

> SigPnd: 0000000000000000

> ShdPnd: 0000000000000000

> SigBlk: fffffffe7bfa7a25

> SigIgn: 0000000000000000

> SigCgt: ffffffffffc1feff

> CapInh: 0000000000000000

> CapPrm: 0000003fffffffff

> CapEff: 0000003fffffffff

> CapBnd: 0000003fffffffff

> CapAmb: 0000000000000000

> NoNewPrivs:     0

> Cpus_allowed:   3

> Cpus_allowed_list:      0-1

> voluntary_ctxt_switches:        92

> nonvoluntary_ctxt_switches:     21

>

> The binary size is 10MB uncompressed and 2MB compressed (xz level 9)

>

> $ cat ocp-server.arm  | xz -9 -c > ocp-server.arm.xz $ ls -l

> ocp-server.arm* - rwxrwxr-x 1 michael_e_brown michael_e_brown 11169052

> Feb 14 13:14 ocp- server.arm

> -rw-rw-r-- 1 michael_e_brown michael_e_brown  2712208 Feb 14 13:26

> ocp- server.arm.xz

>

> The source is currently sitting at under 5k LoC implementing a few

> proof of concept openbmc implementations calling DBUS, as well as a simulation.

>

> Concurrency:

> - Highly concurrent. On ARM serves >300 requests per second. On X86,

> goes up to about 3k requests per second

> - For individual requests: can concurrently get data from multiple

> data sources and runs all the plugins for a redfish resource in

> parallel

>

> Deterministic:

> - The design should be fairly deterministic.

>

> Cached:

> - Completely flexible here. The default model is caching the data, but

> it's also supported to make dbus calls per request (though that's not

> really recommended). Currently it caches sensor results and refreshes

> those at a fixed interval, though that could easily be changed.

>

> Platform dependent/independent:

> - Core is completely platform independent.

> - Working on an OCP profile implementation that also has platform

> independent + platform specific hooks. Currently in place are

> simulation implementation plus openbmc dbus implementation for sensors

> (temperature now, working fans next).

>

> DMTF support:

> - In progress. Help needed.

>

> --

> Michael

>

> On Wed, Feb 07, 2018 at 03:48:41AM +0000, Yugi Mani wrote:

> > Here are some more requirements based on our experience with Redfish:

> > 1. Concurrency

> > Web Server and Framework should be able to serve multiple GET

> > requests

> at a time.

> > POST/PATCH/PUT/DELETE requests can be sequential.

> >

> > 2. Deterministic

> > Service should be time deterministic, both boot time and run time.

> > Concurrency shall not impact deterministic property of the service.

> > All requests shall be responded (success/failure) within acceptable

> > time

> limits.

> > Where some requests cannot be completed within time limits, service

> > shall respond with status and expected time to complete.

> >

> > 3. Cached Data

> > Data shall be cached by Redfish service and updated on dbus signals.

> > Collecting required information on demand adversely impacts

> performance.

> > Redfish should rather cache the information and keep updating its

> > cache on notification from dbus that the property(ies) of interest

> > has been

> modified.

> >

> > 4. Platform dependent/independent layer Shall provide a clear

> > isolation between core vs platform properties.

> > Can consider object oriented approach for platform & oem layer to

> > override core methods and objects. Customized hooks and handlers can

> > be provided by platform layer while the data model between layers is

> > maintained consistent across platforms.

> >

> > 5. DMTF Support

> > Redfish have quite a lot of gaps in some of the basic requirements

> > of a

> BMC.

> > a) FRU & FRU Collection Schema

> > b) Sensor & Sensor Collection Schema

> > c) Component Firmware Update (PSU, BIOS, CPLD, etc)

> > d) Master Write-Read

> > e) Clear PSU Faults

> > We need DMTF to actively add/update Redfish schemas that are

> fundamental to any BMC.

> >

> > 7. Error Codes

> > Redfish LogEntry schema doesn’t offer a placeholder for error codes

> > that automation tools can read to categorize the events and trigger

> actuators.

> > One option is to repurpose OEM field.

> >

> > 8. Pagination

> > Event logs can get too big and paginated view is helpful

> >

> > 9. Filtering

> > Query parameter to filter the response limited to certain criteria

> >

> > 10. Anchors

> > Schemas like Chassis and Manager have a bunch of properties that not

> > all requests might be interested in.

> > It is better to be able to request just a fragment of a resource using ‘#’.

> >

> > 11. Rate Limiting

> > Server shall return HTTP 429 when number of requests cross max limit

> permissible from a client.

> > We need some protection against Denial of Service.

> >

> > -Yugi





[-- Attachment #1.2: Type: text/html, Size: 42918 bytes --]

[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 105 bytes --]

RE: Redfish on OpenBMC

[Stewart Smith]

Hariharasubramanian Ramasubramanian <hramasub@in.ibm.com> writes:
> Replied inline.

Can you all please get a proper mail client so we can read what's going on?

For a start, replying with colours creates an actively hostile work
environment for those who may not see colours the way you do.

Secondly, for those not using HTML mail, it's *completely* unreadable.
-- 
Stewart Smith
OPAL Architect, IBM.