Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-state-manager / ef7abe193ea5b73b36f81da35add5b7e24b49669
commitef7abe193ea5b73b36f81da35add5b7e24b49669[log] [tgz]
authorCarol Wang <wangkair@cn.ibm.com>Tue Feb 25 16:19:34 2020 +0800
committerCarol Wang <wangkair@cn.ibm.com>Mon Mar 30 14:14:41 2020 +0800
treef6e8b94108ea7b08e32b0310b238c152fb561443
parent6a5db3d3bfe5e6f3cec2ee0efd83ebb2d65b6093 [diff]
sched-host-tran: handle with BMC time changing

Handle with different processes when BMC time is changed after scheduled time
is set.

Tested:
Case1: BMC time is changed to be later than current time but still earlier than
scheduled time
1. Get current time
 # date
   Tue Feb 25 07:07:44 UTC 2020
 # date +%s
   1582614271
2. Schedule time, do host transition after at 07:20:00 around
 # busctl get-property xyz.openbmc_project.State.ScheduledHostTransition \
   /xyz/openbmc_project/state/host0 \
   xyz.openbmc_project.State.ScheduledHostTransition ScheduledTime
   t 1582615256
3. Change BMC time to 07:19:00 around
 # busctl set-property xyz.openbmc_project.Time.Manager \
   /xyz/openbmc_project/time/bmc xyz.openbmc_project.Time.EpochTime Elapsed \
   t 1582615136000000
 # date
   Tue Feb 25 07:19:20 UTC 2020
 # date +%s
   1582615187
4. Host transition is done after 1 minute around,
   instead of waiting 13 mins around.

Case2: BMC time is changed after scheduled time is reached
Following Case1, the scheduled time is reached already,
1. Change BMC time to 07:10:00 around
 # busctl set-property xyz.openbmc_project.Time.Manager \
   /xyz/openbmc_project/time/bmc xyz.openbmc_project.Time.EpochTime Elapsed \
   t 1582614600000000
2. APP shows "The function Scheduled Host Transition is disabled", because
   the scheduled time is reached already and the scheduled time has been set
   to 0 after host transition is triggered.

Case3: BMC time is changed to be bigger than scheduled time before scheduled
time is reached
1. Set scheduled time 07:08:00 around
 # busctl set-property xyz.openbmc_project.State.ScheduledHostTransition \
   /xyz/openbmc_project/state/host0 \
   xyz.openbmc_project.State.ScheduledHostTransition ScheduledTime t 1582787314
2. Change BMC time to 07:10:00 around
 # busctl set-property xyz.openbmc_project.Time.Manager \
   /xyz/openbmc_project/time/bmc xyz.openbmc_project.Time.EpochTime Elapsed \
   t 1582787434000000
3. It will do host transition as requested.

Case4: BMC time is changed to be earlier than current time
1. Set scheduled time 07:10:00 around
 # busctl set-property xyz.openbmc_project.State.ScheduledHostTransition \
   /xyz/openbmc_project/state/host0 \
   xyz.openbmc_project.State.ScheduledHostTransition ScheduledTime t 1582787434
2. Change BMC time to 07:08:00 around
 # busctl set-property xyz.openbmc_project.Time.Manager \
   /xyz/openbmc_project/time/bmc xyz.openbmc_project.Time.EpochTime Elapsed \
   t 1582787314000000
3. App will wait 2 minutes more to do host transition.

Change-Id: I23228be944d1b2f71161317228c8b16d7f5ca4eb
Signed-off-by: Carol Wang <wangkair@cn.ibm.com>
3 files changed
tree: f6e8b94108ea7b08e32b0310b238c152fb561443
  1. data/
  2. service_files/
  3. target_files/
  4. test/
  5. .clang-format
  6. .clang-tidy
  7. .gitignore
  8. bmc_state_manager.cpp
  9. bmc_state_manager.hpp
  10. bmc_state_manager_main.cpp
  11. chassis_state_manager.cpp
  12. chassis_state_manager.hpp
  13. chassis_state_manager_main.cpp
  14. discover_system_state.cpp
  15. host_check_main.cpp
  16. host_state_manager.cpp
  17. host_state_manager.hpp
  18. host_state_manager_main.cpp
  19. LICENSE
  20. MAINTAINERS
  21. meson.build
  22. meson_options.txt
  23. obmcutil
  24. README.md
  25. scheduled_host_transition.cpp
  26. scheduled_host_transition.hpp
  27. scheduled_host_transition_main.cpp
  28. settings.cpp
  29. settings.hpp
  30. systemd_target_monitor.cpp
  31. systemd_target_parser.cpp
  32. systemd_target_parser.hpp
  33. systemd_target_signal.cpp
  34. systemd_target_signal.hpp
README.md

Phosphor State Manager Documentation

This repository contains the software responsible for tracking and controlling the state of different objects within OpenBMC. This currently includes the BMC, Chassis, and Host. The most critical feature of phosphor-state-manager software is its support for requests to power on and off the system by the user.

This software also enforces any restore policy (i.e. auto power on system after a system power event or bmc reset) and ensures its states are updated correctly in situations where the BMC is rebooted and the chassis or host are in on/running states.

This repository also provides a command line tool, obmcutil, which provides basic command line support to query and control phosphor-state-manager applications running within an OpenBMC system. This tool itself runs within an OpenBMC system and utilizes D-Bus APIs. These D-Bus APIs are used for development and debug and are not intended for end users.

As with all OpenBMC applications, interfaces and properties within phosphor-state-manager are D-Bus interfaces. These interfaces are then used by external interface protocols, such as Redfish and IPMI, to report and control state to/by the end user.

State Tracking and Control

phosphor-state-manager makes extensive use of systemd. There is a writeup here with an overview of systemd and its use by OpenBMC.

phosphor-state-manager follows some basics design guidelines in its implementation and use of systemd:

  • Keep the different objects as independent as possible (host, chassis, bmc)
  • Use systemd targets for everything and keep the code within phosphor-state-manager minimal
  • Ensure it can support required external interfaces, but don't necessarily create 1x1 mappings otherwise every external interface will end up with its own special chassis or host state request
  • If something like a hard power off can be done by just turning off the chassis, don't provide a command in the host to do the same thing

phosphor-state-manager implements states and state requests as defined in phosphor-dbus-interfaces for each object it supports.

  • bmc: The BMC has very minimal states. It is Ready once all services within the default.target have executed. The only state change request you can make of the BMC is for it to reboot itself.
    • CurrentBMCState: NotReady, Ready
    • RequestedBMCTransition: Reboot
  • chassis: The chassis represents the physical hardware in which the system is contained. It usually has the power supplies, fans, and other hardware associated with it. It can be either On or Off.
    • CurrentPowerState: On, Off
    • RequestedPowerTransition: On, Off
  • host: The host represents the software running on the system. In most cases this is an operating system of some sort. The host can be Off, Running, Quiesced(error condition), or in DiagnosticMode(collecting diagnostic data for a failure)
    • CurrentHostState: Off, Running, Quiesced, DiagnosticMode
    • RequestedHostTransition: Off, On, Reboot, GracefulWarmReboot, ForceWarmReboot

As noted above, phosphor-state-manager provides a command line tool, obmcutil, which takes a state parameter. This will use D-Bus commands to retrieve the above states and present them to the user. It also provides other commands which will send the appropriate D-Bus commands to the above properties to power on/off the chassis and host (see obmcutil --help within an OpenBMC system).

The above objects also implement other D-Bus objects like power on hours, boot progress, reboot attempts, and operating system status. These D-Bus objects are also defined out in the phosphor-dbus-interfaces repository.

Restore Policy on Power Events

The RestorePolicy defines the behavior the user wants when the BMC is reset. If the chassis or host is on/running then this service will not run. If they are off then the RestorePolicy will be read and executed by phosphor-state-manager code.

BMC Reset with Host and/or Chassis On

In situations where the BMC is reset and the chassis and host are on and running, its critical that the BMC software do two things:

  • Never impact the state of the system (causing a power off of a running system is very bad)
  • Ensure the BMC, Chassis, and Host states accurately represent the state of the system.

Note that some of this logic is provided via service files in system-specific meta layers. That is because the logic to determine if the chassis is on or if the host is running can vary from system to system. The requirement to create the files defined below and ensure the common targets go active is a must for anyone wishing to enable this feature.

phosphor-state-manager discovers state vs. trying to cache and save states. This ensure it's always getting the most accurate state information. It discovers the chassis state by checking the pgood value from the power application. If it determines that power is on then it will do the following:

  • Create a file called /run/openbmc/chassis@0-on
    • The presence of this file tells the services to alter their behavior because the chassis is already powered on
  • Start the obmc-chassis-poweron@0.target
    • The majority of services in this target will "fake start" due to the file being present. They will report to systemd that they started and ran successfully but they actually do nothing. This is what you would want in this case. Power is already on so you don't want to run the services to turn power on. You do want to get the obmc-chassis-poweron@0.target in the Active state though so that the chassis object within phosphor-state-manager will correctly report that the chassis is On
  • Start a service to check if the host is on

The chassis@0-on file is removed when power is removed from the chassis.

The logic to check if the host is on sends a command to the host, and if a response is received then similar logic to chassis is done:

  • Create a file called /run/openbmc/host@0-on
  • Start the obmc-host-start@0.target
    • Similar to above, most services will not run due to the file being created and their service files implementing a "ConditionPathExists=!/run/openbmc/host@0-request"

The host@0-on file is removed when the host is stopped.

Building the Code

To build this package, do the following steps:

    1. meson build
    2. ninja -C build

To clean the repository again run `rm -rf build`.