Preventing a system power on before BMC Ready

[Andrew Geissler]

> On May 2, 2023, at 7:48 PM, Ed Tanous <ed at tanous.net> wrote:
> 
> 
> 
> On Tue, May 2, 2023 at 1:49 PM Andrew Geissler <geissonator at gmail.com <mailto:geissonator at gmail.com>> wrote:
> >
> > That got us brainstorming about some possible solutions:
> > - Write some code in bmcweb to send a “bmc state change event” anytime bmcweb
> >   comes up to ensure listening clients know “something” has happened
> > - Add an optional compile option to bmcweb (or PSM/x86-power-control) to require
> >   BMC Ready before issuing chassis or system POST requests (return error if not
> >   at Ready)
> 
> PSM or x86-power-control mods would be my preference.  bmcweb should not be in charge of business logic.  If the system shouldn't allow power on while the bmc is in ready state, then the daemons that handle power on need to have that as a constraint, otherwise you'd have the same problem if a user tried from IPMI.

Thanks for the responses guys. I’m going to go down the path of an optional config
option to PSM that will require BMC Ready for chassis or host operations. It will
return a well defined d-bus error that bmcweb can look at and return an error
to the redfish client indicating the operation is not possible (and when they should retry).

Long term, we’d really like to see the power on/off operations return a redfish
task so clients could track the power operation vs. the required polling and/or boot
event notifications by them now. That timeline for us is out there a bit though.

> > - Queue up the power on request and execute it once we reach BMC Ready (not sure
> >   what type of response that would be to Redfish clients or what error path
> >   looks like if we never reach Ready?)
> 
> Redfish has async tasks for this exact use case, and we already have code to do them.  Alternatively you could just return an error that the operation is not possible, along with a retry-after header instructing the user when to retry their request.  We do this in the few update apis already.

Yep, I like the alternative here medium term.

> 
> > - Find a way in the client to better detect an unexpected bmc reboot (heartbeat
> >   of some sort)
> > - Push bmcweb further in the startup to BMC Ready, ensuring clients can't talk
> >   to the BMC until it's near Ready state
> 
> For your use case, if this is possible, that’s probably easiest and most client friendly, so long as you can handle the case where the bmc never hits “ready”

Possible, but our redfish client does potentially manage a lot of systems, so anything that
increases repeated traffic is frowned upon. And since this seems like something that could
affect any Redfish client with similar event driven requirements, it seems best to ensure
the openbmc back end provides an adequate error in this situation.

> 
> >
> > Thoughts?
> > Andrew
> -- 
> -Ed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230509/96166c75/attachment.htm>