Redfish on OpenBMC
Tanous, Ed
ed.tanous at intel.com
Fri Feb 23 09:30:45 AEDT 2018
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 at dell.com [mailto:Michael.E.Brown at dell.com]
> Sent: Thursday, February 22, 2018 2:03 PM
> To: alirhas at microsoft.com; yupalani at microsoft.com
> Cc: Paul.Vancil at dell.com; hramasub at in.ibm.com; Balaji.B.Rao at dell.com;
> bradleyb at fuzziesquirrel.com; Tanous, Ed <ed.tanous at intel.com>;
> jwcarman at us.ibm.com; openbmc at lists.ozlabs.org;
> pradeep.kumar36 at tcs.com; rolfb at us.ibm.com; Chris.Ong at 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 at microsoft.com]
> Sent: Thursday, February 22, 2018 3:54 PM
> To: Brown, Michael E <Michael_E_Brown at Dell.com>; Yugi Mani
> <yupalani at microsoft.com>
> Cc: Vancil, Paul <Paul_Vancil at Dell.com>; hramasub at in.ibm.com; Rao, Balaji
> B <Balaji_B_Rao at dell.com>; bradleyb at fuzziesquirrel.com;
> ed.tanous at intel.com; jwcarman at us.ibm.com; openbmc at lists.ozlabs.org;
> pradeep.kumar36 at tcs.com; rolfb at us.ibm.com; Chris Ong
> <Chris.Ong at 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 at dell.com>
> Sent: Wednesday, February 14, 2018 11:37 AM
> To: Yugi Mani <yupalani at microsoft.com>
> Cc: Ali Larijani <alirhas at microsoft.com>; Paul.Vancil at dell.com;
> hramasub at in.ibm.com; Michael.E.Brown at dell.com; Balaji.B.Rao at dell.com;
> bradleyb at fuzziesquirrel.com; ed.tanous at intel.com;
> jwcarman at us.ibm.com; openbmc at lists.ozlabs.org;
> pradeep.kumar36 at tcs.com; rolfb at us.ibm.com; Chris Ong
> <Chris.Ong at 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
More information about the openbmc
mailing list