IPMI Maintainer Call Notes - 1/16/2018

[Emily Shaffer]

Meeting: 1/16/2018

Attendees: Emily, Tom, Vernon

Agenda:

   -

   Discuss how to share IPMI stack review practices with community: 48 hour
   minimum review soak, ⅔ maintainer approvals, how and when to initiate
   design discussions
   -

      Add README to cover communication channels
      -

      README should include testing guidelines. (Do we need a Tested: line,
      or do we need new unit tests included with commit, or…?)
      -

      Net-ipmid has infrastructure for unit tests
      -

      Host-ipmid maybe works with make check - Emily will look into it
      -

      Robot test cases for new commands - ideally, committers adding new
      commands should also add robot cases.
      -

      New command: parse input, dbus calls, response. All via ipmitool
      -

      Robot test is run nightly(ish) vs master. And is run against internal
      IBM releases. Exercises REST and IPMI. Stored [
      https://github.com/openbmc/openbmc-test-automation]
      -

      If we could already have an easy howto for writing new commands, or
      example test, then it’s easy to require that as a part of commit.
      -

      As maintainers, we should try to find time to add sample tests.
      -

      Decision: *New commands should have written test included (robot or
      unit), maintainers should make time to add test suite for people
to use as
      example*


   -

   Cover goals for 2018 (what needs to be implemented)
   -

      IBM: Entire standard by end of Q1. DCMI spec - all mandatory commands
      (or close). SDR support needs to be expanded - virtual, hardware sensors;
      FRU records (fru print, sdr list, sensor list). Planning to build on
      existing SDR work. IBM also interested in IPMI user management (but lower
      priority) - IPMI password instead of default account/default pw; user
      should be able to change pw.  Mostly missing mandatory commands.
      -

      Intel: Sensor/fru/sdr needs - already written, pushing soon!
      Interface changes to support min/max/etc - sensors automatically probed
      based on FRU API… SDRs automatically generated from sensor config over
      dbus. Works with ipmitool sensor list. FRU API on DBus that everyone will
      conform with. Chassis probe, json load, expansion probe, ….
Possible it’ll
      go to Intel fork so we can see it. Working on networking IPMI commands,
      get/set network parameters (LAN config), trying to fill out as
much of the
      spec as possible.  Either refactoring or adding more functionality. Also
      have effort on user management [doc change here]. Very interested in
      refactor effort. Firmware update work (eventually) - figuring out which
      standard to use. Both in-band and out-of-band - let’s get
everyone on same
      page
      -

      Google: FRUs.  Entity association record (p536) - SDR. Voltage
      regulator (08h).  (Possibly talk to James Feist about whether
he’s done it
      already.)
      -

   Discuss existing design flaws and potential refactor efforts
   -

      SDR infrastructure.  Vernon had mentioned autogenerated SDR @ Intel.
      Based on probing FRU to find which groups of sensors exist.
Based on that,
      there’s a JSON file with those sensors’ configs. Systems are in
      configuration groups based on card that’s present or not.  A device tree
      overlay call happens for hwmon sensors and a scanning daemon is
started for
      each group (on first boot).  Vernon, get Ed & James to put this
into Intel
      public fork so we can look at it.  FRUs detected by BMC.  Base FRU in
      flash, other FRUs discovered over DBus? Write own FRU parser as necessary
      for own FRU format.  IBM gets FRU location info from hostboot pushed over
      IPMI.  BMC can store FRU format info if it ever shows up from
hostboot, so
      it will work with hostboot as source of truth or BMC as source of truth.
      Maybe James F can talk about it on community telecom.
      -

      Getting rid of sdbus -> move to sdbusplus (inline with OpenBMC effort
      project-wide)
      -

      Split network ipmid into network daemon to network & dbus (similar to
      btbridged) - do we want to then keep both IPMI daemons, or note which
      bridge sourced the request and handle it based on that. Security
concern -
      network is attack vector, minimize how much network comm can touch.
      Running network daemon as user with few permissions/access is safer - if
      it’s compromised, still no risk.  Inline with effort to make all daemons
      nonroot (except systemd).  Inline with SELinux talk from
hackathon - maybe
      we can get some guidance from Dell. Separating daemons into users is
      orthogonal but still helpful
      -

   Determine best way for asynchronous communication between the three of
   us.
   -

      Email good for people during work hours, or for extended
      conversations.  Riot good for pings, high-priority small things. No
      frivolous communication on Riot (since we get notifications)
      -

   Do we want to communicate result of these maintainer meetings??
   -

      Send an email with the governance info for commits etc.  Emily will
      ping Brad and find out how much information to share
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180117/81d6832f/attachment-0001.html>