Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent host/chassis power states #3

Open
AlexanderAmelkin opened this issue Jan 22, 2019 · 2 comments
Open

Inconsistent host/chassis power states #3

AlexanderAmelkin opened this issue Jan 22, 2019 · 2 comments

Comments

@AlexanderAmelkin
Copy link

Currently, there are two items in REST that, being changed, directly affect the host power:

  1. /xyz/openbmc_project/state/chassis0/RequestedPowerTransition
  2. /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.

@geissonator
Copy link
Contributor

One thing we want to be sure we're doing is moving towards an API that would support the Redfish API's.

curl -k -H "X-Auth-Token: $bmc_token" -X POST https://${bmc}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset -d '{"ResetType": "On"}'

curl -k -H "X-Auth-Token: $bmc_token" -X POST https://${bmc}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset -d '{"ResetType": "GracefulShutdown"}'

curl -k -H "X-Auth-Token: $bmc_token" -X POST https://${bmc}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset -d '{"ResetType": "ForceOff"}'

curl -k -H "X-Auth-Token: $bmc_token" -X POST https://${bmc}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset -d '{"ResetType": "GracefulRestart"}'

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.

https://github.com/openbmc/bmcweb/blob/947326618971c0f658f4a5348df2f47d8819b165/redfish-core/lib/systems.hpp#L570 is the implementation of redfish in bmcweb right now and you can see it going down the chassis vs. host path based on the command.

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?

Thoughts @edtanous @gtmills @dkodihal @anoo1 or @vishwabmc (or anyone else)?

@AlexanderAmelkin
Copy link
Author

I'd say that RequestedPowerTransition is redundant and is not needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants