Chassis reset

[Ed Tanous]

On Tue, Sep 29, 2020 at 3:14 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 9/23/20, 7:24 PM, "Ed Tanous" <ed at tanous.net> wrote:
>
>     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.
>
> I am actually asserting a pin by sending i2c command to HSC (Hot swap controller)
> Which removes power and restores back.

That doesn't change anything in this regard.  Regardless of the
physical medium, the end result is that power is removed, then
restored.  That's a PowerCycle action.

>
>     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.
>
> Then should we map this chassis powercycle to chassis_system0 in the code?
>

yes, if chassis_system0 is supported on that platform.  If it's not,
it should fall back to the old chassis0 node, so we don't break
anyone.