Chassis reset
Ed Tanous
ed at tanous.net
Sat Sep 19 10:17:15 AEST 2020
On Fri, Sep 18, 2020 at 4:28 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 9/18/20, 2:38 PM, "Ed Tanous" <ed at tanous.net> wrote:
>
> On Fri, Sep 18, 2020 at 12:52 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
> >
> > Team,
> >
> > I am again want to discuss complete system reset. We had discussion in past for this and I implemented this as a chassis instance system_chassis0 and allowed user to initiate PowerCycle which will reset the complete system.
> >
> > Please help me understand following scenario
> >
> > Host reset – resetting host only
>
> Should be done by initiating a reset action on the
> /redfish/v1/Systems/system endpoint.
>
> > Chassis reset – resetting host and bmc via single command.
>
> IMO, this shouldn't be supported as a single command in redfish. If
> you want this behavior, issue a reset to the System resource similar
> to above, then issue a separate reset action to the Manager resource
> at /redfish/v1/Managers/bmc.
>
> In less complicated terms, I tend to abstract these kinds reset down to:
> System reset: Reset as if I'd done a soft/hard reset of the main host processor
> Chassis reset: Reset as if I'd unplugged the particular component from
> mains power (AC or DC)
> Manager reset: Reset as if I'd done a soft/hard reset of the BMC
> I completely agree with you on above part.
>
> Per the above, if you're looking for a chassis level reset (IE pulling
> main power) this should be done in a Chassis Resource.
> Then chassis reset should call proper chassis reset dbus command.
Um.... Either I'm terrible at reading code, or it already does?
Codelink to the Chassis schema calling the
/xyz/openbmc_project/state/chassis0 URL:
https://github.com/openbmc/bmcweb/blob/23e64207a6668319df1f273641febdeab4c09148/redfish-core/lib/chassis.hpp#L527
>
> > System reset – This is a hard reset of complete system including every device.
>
> This is I think the new one you're adding, and should be modeled under
> a new chassis resource /redfish/v1/Chassis/<Chassis name>, and by
> issuing a ForceReset action to it. I know in the past, for systems
> that weren't capable of initiating a full chassis reset, we've modeled
> this as a host reset for compatibility purposes. It should be noted,
> this is arguably "wrong" but kept around because we weren't prepared
> to break client implementations that expected that action to be there.
>
> As a side note, is anyone a PMBUS expert? A quick look at the spec
> seems like there should be a way to issue an AC-reset to a PMBUS
> enabled power supply, but I got stuck reading the docs, given the
> complexities of modern power supplies. Is there someone that just
> knows the magic string to send to it? In that way, we could implement
> the above in the "right" way, while still not breaking peoples
> compatibility with the older interfaces. Now back to Vijay.
>
> I'm assuming a lot of this is in context to your current patch:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_bmcweb_-2B_36557&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=WsoH-XNAOK3Qh6X9q0ZjO_7QfoFm35nc2VMby37UTgQ&s=1IYYiDRN_ZeEB6NAu1X3kgvDNYCopzpgvsEXqqFVmH4&e=
>
> Your existing patch doesn't work because you're modifying the
> Redfish-provided enums to add your new action, when redfish would
> recommend adding a resource specific to that physical box that can
> call your new endpoint.
> I didn't know about redfish action schema, I will change that.
The Redfish actions are how all power state changes are modeled today.
It's a good thing to know if you're diving into this stuff.
>
> >
> >
> >
> > Redfish defines only above 2 type and system reset can be covered under chassis reset.
>
> I'm not really following this. Redfish exposes the different types
> you need through multiple Chassis Resources. If you have a higher
> level chassis that contains items below it, you would have a new
> Chassis resource, which implements a Reset action on it.
>
> I'm going to go out on a limb and assume you're working on Tioga for a
> moment. I would expect that the Tioga Sled to have one chassis, and
> the Tioga BladeCenter to have another chassis, with ContainedBy,
> Contains, and PoweredBy links in the appropriate places on each.
>
> > As per implementation in x86-power-control, host reset and chassis reset both takes same action like rebooting host only. For system reset it has a separate interface system_chassis0 and PowerCycle command triggers this reset.
>
> I'm really surprised that this chassis level reset would go in
> x86-power-control. That daemon is really for host level control, not
> chassis, and considering that almost every implementation is going to
> have a different way to "pull the power" I'd expect these to go in a
> different repo, or at the very least a different application, so the
> various BMCs can swap them out with the correct one for their chassis.
> I probably missed a discussion on this a while back.
>
> This was added as a systemd target call on this command. So power control will
> Call user defined system reset target service on issue or system reset command
> And each platform can develop their own target like setting some i2c register or
> Setting some gpio.
That's a good extension mechanism, but really it should live in a
separate daemon. Not all power state management requires systemd
targets, or can handle the latency imposed there. Also there are a
lot of cases that can fail in hardware, and require holding the
message return to dbus until the hardware has been exercised, and that
kinds of error handling tend to be difficult to do on systemd
targets..
>
> >
> >
> >
> > Please help me how do I support this system reset in redfish.
>
> Hopefully the above helps!
> Thanks, It does helps a lot. I would submit a new patch.
Great. Happy to help.
>
> >
> >
> >
> > Regards
> >
> > -Vijay
>
More information about the openbmc
mailing list