Chassis reset

[Ed Tanous]

On Wed, Sep 23, 2020 at 6:59 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>     >
>     > I'm not understanding what you mean by "come up with an API to steer the
>     > Redfish..."  I think everything is specified here at a dbus level.  The
>     > issue is figuring out the appropriate Redfish model of
>     > Chassis/ComputerSystem objects (along with the included Resource.Reset
>     > types).  To a casual reader, who hasn't been involved much in Redfish
>     > implementation, the current mapping of these ResetTypes seems fairly
>     > arbitrary.
>
>     Some might be arbitrary, but most are explicit and chosen on purpose,
>     especially in the case of the System schema.  The Chassis schema is a
>     little more lax, as it's more of a backward compatibility thing today.
>     I think you (Vijay) are the first person trying to model it
>     "properly".
>
>     What I mean is that the current Redfish definition of Chassis points
>     the PowerCycle action to chassis0.  That PowerCycle action now needs
>     to point at multiple things, chassis0 if we don't support AC reset, or
>     chassis_system0 if we do.  That is the "steering" I was referring to.
>
> How about we map powerCycle to chassis0 and ForceRestart to chassis_system0
>
>

I would not be in favor of this.  Technically you're implementing a
PowerCycle here as you're cycling the power supplies off then on.  A
ForceReset would be if you asserted some kind of reset pin to the
board, while keeping the power supplies up, which, while valid, is not
what you're doing.
Also, it would mean that we have multiple actions to maintain
externally, and users would have no guarantees about which ones are
supported.  Mapping PowerCycle to the best supported mechanism we have
seems like the best thing to do here.