commit | ba182f0c14791f244fb5468d640c0fa75b7e08da | [log] [tgz] |
---|---|---|
author | Allen.Wang <Allen_Wang@quantatw.com> | Wed Mar 23 19:01:53 2022 +0800 |
committer | Andrew Geissler <andrew@geissonator.com> | Fri Apr 22 19:26:43 2022 +0000 |
tree | 2e38284e03e911bc46926e8e0523a8be83de4ffa | |
parent | 106152c64631979b04cdb624ae32755ea1802603 [diff] |
phosphor-state-manager: Support multi-host for persist files phosphor-host-state-manager and phosphor-chassis-state-manager store informations in files then restore that on service starting. Since state-managers already change to multi-host now, information should store into different files from each service instance. forbackward capability, if there are legacy persist file exist, rename it to the new file format of instance ;0',i.e, rename files: 'requestedHostTransition' to 'host0-PersistData', 'POHCounter' to 'chassis-POHCounter', 'chassisStateChangeTime' to 'chassis0-StateChangeTime' Changes: a.phosphor-host-state-manager: '/var/lib/phosphor-state-manager/requestedHostTransition' this file not only store requestedHostTransition now, rename to PersistData and add host-N prefix for each service. For example, bus xyz.openbmc_project.State.Host1 store data to '/var/lib/phosphor-state-manager/host1-PersistData' xyz.openbmc_project.State.Host2 store date to '/var/lib/phosphor-state-manager/host2-PersistData' b.phosphor-chassis-state-manager: There are two files to store informations '/var/lib/phosphor-state-manager/POHCounter', '/var/lib/phosphor-state-manager/chassisStateChangeTime' change to: '/var/lib/phosphor-state-manager/chassis1-POHCounter', '/var/lib/phosphor-state-manager/chassis2-POHCounter' ... '/var/lib/phosphor-state-manager/chassis1-StateChangeTime' '/var/lib/phosphor-state-manager/chassis2-StateChangeTime' ... for each service. Tested on Bletchley HW, set xyz.openbmc_project.State.Host1 RequestedHostTransition to On 'busctl set-property xyz.openbmc_project.State.Host1 /xyz/openbmc_project/state/host1 xyz.openbmc_project.State.Host RequestedHostTransition s "xyz.openbmc_project.State.Host.Transition.On"' This request will store in file: 'cat /var/lib/phosphor-state-manager/host1-PersistData' { "value0": { "cereal_class_version": 1, "value0": "xyz.openbmc_project.State.Host.Transition.On", "value1": "xyz.openbmc_project.State.Boot.Progress.ProgressStages.Unspecified", "value2": "xyz.openbmc_project.State.OperatingSystem.Status.OSStatus.Inactive" } restart xyz.openbmc_project.State.Host1~Host6 or reboot BMC, 'RequestedHostTransition' for host1 still "On" 'busctl get-property xyz.openbmc_project.State.Host1 /xyz/openbmc_project/state/host1 xyz.openbmc_project.State.Host RequestedHostTransition' s "xyz.openbmc_project.State.Host.Transition.On" 'RequestedHostTransition' of the rest 5 Hosts are default value "xyz.openbmc_project.State.Host.Transition.Off" Also, set POHCounter of xyz.openbmc_project.State.Chassis2 'busctl set-property xyz.openbmc_project.State.Chassis2 /xyz/openbmc_project/state/chassis2 xyz.openbmc_project.State.PowerOnHours POHCounter u 5' it will restore after service restart or BMC reboot, 'busctl get-property xyz.openbmc_project.State.Chassis2 /xyz/openbmc_project/state/chassis2 xyz.openbmc_project.State.PowerOnHours POHCounter' u 5 Change-Id: I739c62707bb805e7c25f399a2fea06beee5543a0 Signed-off-by: Allen.Wang <Allen_Wang@quantatw.com>
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.
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:
phosphor-state-manager implements states and state requests as defined in phosphor-dbus-interfaces for each object it supports.
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.On
or Off
.Off
, Running
, Quiesced
(error condition), or in DiagnosticMode
(collecting diagnostic data for a failure)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.
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.
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:
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:
On
The chassis@0-on file is removed once the obmc-chassis-poweron@0.target becomes active (i.e. all service have been successfully started which are wanted or required by this target).
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:
The host@0-on file is removed once the obmc-host-start@0.target and obmc-host-startmin@0.target become active (i.e. all service have been successfully started which are wanted or required by these targets).
To build this package, do the following steps: 1. meson build 2. ninja -C build To clean the repository again run `rm -rf build`.