Chassis reset

[Vijay Khemka]

On 9/29/20, 3:22 PM, "Ed Tanous" <ed at tanous.net> wrote:

    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.

Ok, Let me figure out this, how to find support. Can I use compile time enable 
for chassis_system0 or should I look for runtime interface.