Inconsistent host/chassis power states #3
Description
Currently, there are two items in REST that, being changed, directly affect the host power:
/xyz/openbmc_project/state/chassis0/RequestedPowerTransition/xyz/openbmc_project/state/host0/RequestedHostTransition
The former, when set to xyz.openbmc_project.State.Chassis.Transition.Off, turns host power off without setting the latter to xyz.openbmc_project.State.Host.Transition.Off. That leads to restoration of host power upon AC power cycle or BMC reboot.
@geissonator argued in review comments to https://gerrit.openbmc-project.xyz/15061 that we must not "imply what the user wants" and thus setting RequestedPowerTransition must not alter RequestedHostTransition.
The problem is that there are user interfaces, such as WebUI and others (IPMI, SNMP, some 3rd-party CLI, etc.), that will all have to reimplement the same approach of setting two properties in the correct order if they want a single 'Forced shutdown' button. That is error prone. In fact, WebUI already has that button and it only sets RequestedPowerTransition and thus suffers from the AC power cycle problem.
What we propose here is introduction of a new value for RequestedHostTransition that would mean a forced host shutdown, will by design turn the chassis power off and not return it upon external power cycle or BMC reboot, and will be the single control handle that all the user interfaces will have to pull when they want a forced host shutdown.
Any arguments against it? We'd like to have a discussion before we put any efforts into development of this feature.