| commit | 9f65dfeaa5ab22cae03db45c9916868da9864f83 | [log] [tgz] |
|---|---|---|
| author | Andrew Geissler <geissonator@yahoo.com> | Thu Nov 05 13:57:51 2020 -0600 |
| committer | Patrick Williams <patrick@stwcx.xyz> | Wed Nov 18 16:07:34 2020 +0000 |
| tree | c71b3ffecb10efde6537eaee0b688b21e18d4e03 | |
| parent | 69a5a7ab9d2135015e4d18c410555ff93671738e [diff] |
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
YAML descriptors of standard D-Bus interfaces. The format is described by the sdbusplus binding generation tool sdbus++.
This project can be built with meson. The typical meson workflow is: meson builddir && ninja -C builddir.
The meson files used to handle the YAML files are automatically generated and found under the gen subdirectory. When adding or removing YAML files, this must be regenerated. This can be done with the helper script found in the gen subdirectory: cd gen && ./regenerate-meson.
Only the xyz/openbmc_project interfaces are built by default. Other interfaces can be enabled by meson options:
-Ddata_com_ibm=true-Ddata_org_open_power=trueExample: meson builddir -Ddata_com_ibm=true && ninja -C builddir