You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
There definitely does not appear to be the concept of a host or chassis so your proposal does seem to get us closer to Redfish. A "System" in redfish seems to basically be an instance of our phosphor host state object.
Would this new RequestedHostTransition also modify RequestedPowerTransition or that would be irrelevant since modifying RequestedPowerTransition would no longer be needed in the normal operation of the system?
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 toxyz.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 alterRequestedHostTransition
.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.
The text was updated successfully, but these errors were encountered: