tree c71b3ffecb10efde6537eaee0b688b21e18d4e03
parent 69a5a7ab9d2135015e4d18c410555ff93671738e
author Andrew Geissler <geissonator@yahoo.com> 1604606271 -0600
committer Patrick Williams <patrick@stwcx.xyz> 1605715654 +0000

transition: support transitioning host states

For a long time it has been requested by multiple people and teams
that state management provide the transitioning states. The
response was that users could look at the CurrentHostState and
RequestedHostTransition and figure it out themselves.
This was never a very reasonable answer though because of the following:
1) There is no way to know if the RequestedHostTransition or
   RequestedPowerTransition was updated last. Unless a timestamp is
   added to track when each is updated, it's difficult for an external
   entity to really know what that last requested system operation was.
2) The host can be stopped for a lot of other reasons then just the
   RequestedHostTransition property being updated (chassis power off,
   critical system failures). There is also a design point that OpenBMC
   applications can go straight to the systemd targets if they wish for
   system control. We don't update the Request* properties in these
   cases because when we implemented the
   xyz/openbmc_project/Control/Power/RestorePolicy.interface, we made a
   defacto (and apparently un-documented rule) that the
   RequestedHostTransition property represents the last user-requested
   state change. This is so the restore policy can restore the system to
   the last user-requested state vs. something the system or software did.

This commit proposes adding these transition states to the HostState
property. Although OpenBMC D-Bus api's are not required to have a
Redfish mapping, there is a "PoweringOn" and "PoweringOff"  PowerState
property associated with the system that these new values will map quite
well to.

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I43d44447819fcc55d86c896abd307baa5a59edb9