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