BMC and Host State Management Refactor

Andrew Geissler geissonator at gmail.com
Sat Nov 19 07:31:41 AEDT 2016


Josh and I are working two stories this sprint that deal with
refactoring the bmc and host state management code out of skeleton
(#772/#783).  Here’s the proposal on this work.

A new repository will be created, phosphor-state-manager.  Within this
repo we will support both the BMC and Host state management functions.
The bmc and host function will be broken into separate objects within
the repo for cases where people only want one or the other.

For host management, we will be moving skeleton/op-hostctl into this
new repo.  The primary responsibility of this code is to initiate a
host power on/off/reboot via systemd and to monitor systemd targets to
maintain a coherent state of the host.  We will also be moving a
portion of op-hostctl into it’s own standalone application that will
be run in a systemd target and do the FSI bit bang magic to start the
SBE/Hostboot. Note that we will be moving a portion of the
skeleton/pychassisctl out as well (specifically the power
on/off/reboot and query functions).

For the BMC state management work we will be moving skeleton/bmcctl
into this new repo.  The primary responsibility of this code will be
to provide reboot and current state information on the BMC.

Note the actual state managemen function is still contained within
systemd and the corresponding units we've associated with it.  This
code we're writing here just iniates the systemd targets on user
requests and tracks the defined states by monitoring systemd progress.

The overall design for both state management objects is that they will
provide a set of properties on which to operate.
- DesiredState
- CurrentState

CurrentState will be a read only property.

The host control will have these additional properties:
- DesiredPowerState
- CurrentPowerState

Valid states to request for OpenBMC (DesiredState)
- READY, REBOOT
Valid states to be in for OpenBMC (CurrentState)
- NOT_READY, READY (note this proposal removes BASE_APPS and BMC_STARTING).

READY implies all services started and running successfully (i.e. we
reached obmc-standby.target)


Valid states to request for Host (DesiredState)
- OFF, ON, REBOOT
Validate states to be in for Host (CurrentState)
- OFF, BOOTING, BOOTED

BOOTED implies petitboot has reached it's "ready" state.


Valid power states to request for DesiredPowerState
- OFF, ON
Validate states to be in for CurrentPowerState
- OFF, TRANSITION, ON

Patrick and I had some discussion on providing more details on the
host booted state (petitboot vs. os booted) but that can be an
extension in the future if needed.

Yaml for review will be available shortly in gerrit.

Comments always welcome!
Andrew and Josh


More information about the openbmc mailing list