Chassis reset

[Ed Tanous]

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

Per the above, if you're looking for a chassis level reset (IE pulling
main power) this should be done in a Chassis Resource.

> 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://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/36557

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.

>
>
>
> 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.

>
>
>
> Please help me how do I support this system reset in redfish.

Hopefully the above helps!

>
>
>
> Regards
>
> -Vijay