<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 2, 2023, at 7:48 PM, Ed Tanous <<a href="mailto:ed@tanous.net" class="">ed@tanous.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">
<br class="">
On Tue, May 2, 2023 at 1:49 PM Andrew Geissler <<a href="mailto:geissonator@gmail.com" target="_blank" class="">geissonator@gmail.com</a>> wrote:<br class="">
><br class="">
> That got us brainstorming about some possible solutions:<br class="">
> - Write some code in bmcweb to send a “bmc state change event” anytime bmcweb<br class="">
> comes up to ensure listening clients know “something” has happened<br class="">
> - Add an optional compile option to bmcweb (or PSM/x86-power-control) to require<br class="">
> BMC Ready before issuing chassis or system POST requests (return error if not<br class="">
> at Ready)<br class="">
<br class=""></div><div class="">
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.</div></div></blockquote><div><br class=""></div><div>Thanks for the responses guys. I’m going to go down the path of an optional config</div><div>option to PSM that will require BMC Ready for chassis or host operations. It will</div><div>return a well defined d-bus error that bmcweb can look at and return an error</div><div>to the redfish client indicating the operation is not possible (and when they should retry).</div><div><br class=""></div><div>Long term, we’d really like to see the power on/off operations return a redfish</div><div>task so clients could track the power operation vs. the required polling and/or boot</div><div>event notifications by them now. That timeline for us is out there a bit though.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
> - Queue up the power on request and execute it once we reach BMC Ready (not sure<br class="">
> what type of response that would be to Redfish clients or what error path<br class="">
> looks like if we never reach Ready?)</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div></div></blockquote><div><br class=""></div><div>Yep, I like the alternative here medium term.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class="">
> - Find a way in the client to better detect an unexpected bmc reboot (heartbeat<br class="">
> of some sort)<br class="">
> - Push bmcweb further in the startup to BMC Ready, ensuring clients can't talk<br class="">
> to the BMC until it's near Ready state</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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”</div></div></blockquote><div><br class=""></div><div>Possible, but our redfish client does potentially manage a lot of systems, so anything that</div><div>increases repeated traffic is frowned upon. And since this seems like something that could</div><div>affect any Redfish client with similar event driven requirements, it seems best to ensure</div><div>the openbmc back end provides an adequate error in this situation.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class="">
><br class="">
> Thoughts?<br class="">
> Andrew<br class="">
</div><span class="gmail_signature_prefix">-- </span><br class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class="">-Ed</div></div>
</div></blockquote></div><br class=""></body></html>