Chassis reset

Chassis reset

[Vijay Khemka]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

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

  1.  Host reset – resetting host only
  2.  Chassis reset – resetting host and bmc via single command.
  3.  System reset – This is a hard reset of complete system including every device.

Redfish defines only above 2 type and system reset can be covered under chassis reset. 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.

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

Regards
-Vijay

[-- Attachment #2: Type: text/html, Size: 4836 bytes --]

Re: Chassis reset

[Ed Tanous]

On Fri, Sep 18, 2020 at 12:52 PM Vijay Khemka <vijaykhemka@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

Re: Chassis reset

[Vijay Khemka]

On 9/18/20, 2:38 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Fri, Sep 18, 2020 at 12:52 PM Vijay Khemka <vijaykhemka@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. 

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

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

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

    >
    >
    >
    > Regards
    >
    > -Vijay

Re: Chassis reset

[Ed Tanous]

On Fri, Sep 18, 2020 at 4:28 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/18/20, 2:38 PM, "Ed Tanous" <ed@tanous.net> wrote:
>
>     On Fri, Sep 18, 2020 at 12:52 PM Vijay Khemka <vijaykhemka@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
>

Re: Chassis reset

[Vijay Khemka]

After a bit of study on redfish, I got some basic definition for chassis from redfish document  as below.
https://redfish.dmtf.org/schemas/v1/Chassis.v1_13_0.json
       "Chassis": {
            "additionalProperties": false,
            "description": "The Chassis schema represents the physical components of a system.  This resource represents the sheet-metal confined spaces and logical zones such as racks, enclosures, chassis and all other containers.  Subsystems, such as sensors, that operate outside of a system's data plane are linked either directly or indirectly through this resource.  A subsystem that operates outside of a system's data plane are not accessible to software that runs on the system.",
            "longDescription": "This resource shall represent a chassis or other physical enclosure for a Redfish implementation.",

In my understanding, chassis reset should be treated as complete power cycle of whole chassis and we can use redfish command "ForceRestart or PowerCycle"

As per our implementation in bmcweb, we have implemented 2 interface (syatem and chassis) where we deal with chassis reset
1.  https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/systems.hpp#L1754
In this system interface every reset type except ForceOff is calling action for host and for ForceOff command, it is calling chassis poweroff.

2. https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/chassis.hpp#L585
Here we only implement "PowerCycle" command.

Why did we implement chassis reset command at 2 different interface, I might be missing something here.

As per x86-power-control, in both above cases chassis command point to action on host only
https://github.com/openbmc/x86-power-control/blob/e63dea0875a70ff50f430a4bdc84b646a56b9ce7/power-control-x86/src/power_control.cpp#L2389

where can we implement action on chassis.

Can I add ForceRestart for chassis in redfish chassis interface as chassis sled (complete power removal and restore)
https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/chassis.hpp#L585

I understand that it is not very clear from refish how to map each resource and command. 

Please suggest a direction here. 

Regards
-Vijay

Re: Chassis reset

[Ed Tanous]

On Tue, Sep 22, 2020 at 12:16 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> After a bit of study on redfish, I got some basic definition for chassis from redfish document  as below.
> https://redfish.dmtf.org/schemas/v1/Chassis.v1_13_0.json
>        "Chassis": {
>             "additionalProperties": false,
>             "description": "The Chassis schema represents the physical components of a system.  This resource represents the sheet-metal confined spaces and logical zones such as racks, enclosures, chassis and all other containers.  Subsystems, such as sensors, that operate outside of a system's data plane are linked either directly or indirectly through this resource.  A subsystem that operates outside of a system's data plane are not accessible to software that runs on the system.",
>             "longDescription": "This resource shall represent a chassis or other physical enclosure for a Redfish implementation.",
>
> In my understanding, chassis reset should be treated as complete power cycle of whole chassis and we can use redfish command "ForceRestart or PowerCycle"

I'd probably guess that in this case we'd map both ForceRestart and
PowerCycle to the same action, if we're just pulling the power rail.

>
> As per our implementation in bmcweb, we have implemented 2 interface (syatem and chassis) where we deal with chassis reset
> 1.  https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/systems.hpp#L1754
> In this system interface every reset type except ForceOff is calling action for host and for ForceOff command, it is calling chassis poweroff.
>
> 2. https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/chassis.hpp#L585
> Here we only implement "PowerCycle" command.
>
> Why did we implement chassis reset command at 2 different interface, I might be missing something here.
>
> As per x86-power-control, in both above cases chassis command point to action on host only
> https://github.com/openbmc/x86-power-control/blob/e63dea0875a70ff50f430a4bdc84b646a56b9ce7/power-control-x86/src/power_control.cpp#L2389

Because most systems don't have the ability to do a complete AC reset,
so today we tend to map a Chassis reset to a host reset for
compatibility.  I suspect your use case is the first system that will
add the ability to do the "right" thing, and actually cycle power to
the chassis.

>
> where can we implement action on chassis.
>
> Can I add ForceRestart for chassis in redfish chassis interface as chassis sled (complete power removal and restore)
> https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/chassis.hpp#L585

You can add ForceRestart, but you need to implement it in such a way
that it's selecting it per-chassis, given that you'll have 2 chassis
instances, one capable of an AC reset, one that isn't.  Today, the
code does the wrong thing, and maps all chassis resets to the
/org/xyz/openbmc_project/chassis0 path, because there was no
association for power state mapping back to a chassis path.  You'll
likely need to do some engineering in this regard, or just map
/org/xyz/openbmc_project/chassis0 to your "chassis" reset.

>
> I understand that it is not very clear from refish how to map each resource and command.
>
> Please suggest a direction here.
>
> Regards
> -Vijay
>

Re: Chassis reset

[Vijay Khemka]

On 9/22/20, 5:17 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Tue, Sep 22, 2020 at 12:16 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    > After a bit of study on redfish, I got some basic definition for chassis from redfish document  as below.
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__redfish.dmtf.org_schemas_v1_Chassis.v1-5F13-5F0.json&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=ZSi4Hs0ENb-D1hq-bMaKWw2R5N_bjlMmJVLI_Tk9eys&s=UKug-p2wtGuxhseB-DvECuTKO_I12O18Y3qLykeAUls&e= 
    >        "Chassis": {
    >             "additionalProperties": false,
    >             "description": "The Chassis schema represents the physical components of a system.  This resource represents the sheet-metal confined spaces and logical zones such as racks, enclosures, chassis and all other containers.  Subsystems, such as sensors, that operate outside of a system's data plane are linked either directly or indirectly through this resource.  A subsystem that operates outside of a system's data plane are not accessible to software that runs on the system.",
    >             "longDescription": "This resource shall represent a chassis or other physical enclosure for a Redfish implementation.",
    >
    > In my understanding, chassis reset should be treated as complete power cycle of whole chassis and we can use redfish command "ForceRestart or PowerCycle"

    I'd probably guess that in this case we'd map both ForceRestart and
    PowerCycle to the same action, if we're just pulling the power rail.

    >
    > As per our implementation in bmcweb, we have implemented 2 interface (syatem and chassis) where we deal with chassis reset
    > 1.  https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/systems.hpp#L1754
    > In this system interface every reset type except ForceOff is calling action for host and for ForceOff command, it is calling chassis poweroff.
    >
    > 2. https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/chassis.hpp#L585
    > Here we only implement "PowerCycle" command.
    >
    > Why did we implement chassis reset command at 2 different interface, I might be missing something here.
    >
    > As per x86-power-control, in both above cases chassis command point to action on host only
    > https://github.com/openbmc/x86-power-control/blob/e63dea0875a70ff50f430a4bdc84b646a56b9ce7/power-control-x86/src/power_control.cpp#L2389

    Because most systems don't have the ability to do a complete AC reset,
    so today we tend to map a Chassis reset to a host reset for
    compatibility.  I suspect your use case is the first system that will
    add the ability to do the "right" thing, and actually cycle power to
    the chassis.

    >
    > where can we implement action on chassis.
    >
    > Can I add ForceRestart for chassis in redfish chassis interface as chassis sled (complete power removal and restore)
    > https://github.com/openbmc/bmcweb/blob/684bb4b89f88b394b00b140d71c161143393f80b/redfish-core/lib/chassis.hpp#L585

    You can add ForceRestart, but you need to implement it in such a way
    that it's selecting it per-chassis, given that you'll have 2 chassis
    instances, one capable of an AC reset, one that isn't.  Today, the
    code does the wrong thing, and maps all chassis resets to the
    /org/xyz/openbmc_project/chassis0 path, because there was no
    association for power state mapping back to a chassis path.  You'll
    likely need to do some engineering in this regard, or just map
    /org/xyz/openbmc_project/chassis0 to your "chassis" reset.

Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
Later one is used for AC reset.

    >
    > I understand that it is not very clear from refish how to map each resource and command.
    >
    > Please suggest a direction here.
    >
    > Regards
    > -Vijay
    >

Re: Chassis reset

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
> 
> Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
> Later one is used for AC reset.

Can we do a query to see if 'chassis_system0' exists and use it first
and then 'chassis0' if not?

I think we need to do some enhancement to x86-power-control though also
to only create this 'chassis_system0' object if configured.  I believe
the current code change you did does it always, even if the
systemd-target is empty.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Chassis reset

[Ed Tanous]

On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
> >
> > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
> > Later one is used for AC reset.
>
> Can we do a query to see if 'chassis_system0' exists and use it first
> and then 'chassis0' if not?

I don't think it's that simple.  The way the dbus APIs are defined,
one Redfish chassis needs to call the chassis0 path, the other needs
to call the chassis_system0 path.  We'd need a way to key off which
one is which.  I haven't seen any entity-manager configs get checked
in for a "multinode chassis" entity type, so whatever interface we use
to describe that will probably be what we need to key off to make that
path distinction.

>
> I think we need to do some enhancement to x86-power-control though also
> to only create this 'chassis_system0' object if configured.  I believe
> the current code change you did does it always, even if the
> systemd-target is empty.

I keep getting the feeling that xyz/openbmc_project/chassis_system0 is
just overloading what /xyz/openbmc_project/chassis0 is intended to do,
x86-power-control just had that already defined, so we went another
direction.  I wonder if we just need to make the "Can I do a real AC
reset" configurable, and have it change the behavior of
/xyz/openbmc_project/chassis0 in that case.

Also, I'll reiterate that a chassis reset really should be going in a
separate repo/application from x86-power-control.  x86-power-control
should be focused on managing the host.

>
> --
> Patrick Williams

Re: Chassis reset

[Vijay Khemka]

On 9/23/20, 12:27 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
    >
    > On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
    > >
    > > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
    > > Later one is used for AC reset.
    >
    > Can we do a query to see if 'chassis_system0' exists and use it first
    > and then 'chassis0' if not?

    I don't think it's that simple.  The way the dbus APIs are defined,
    one Redfish chassis needs to call the chassis0 path, the other needs
    to call the chassis_system0 path.  We'd need a way to key off which
    one is which.  I haven't seen any entity-manager configs get checked
    in for a "multinode chassis" entity type, so whatever interface we use
    to describe that will probably be what we need to key off to make that
    path distinction.

    >
    > I think we need to do some enhancement to x86-power-control though also
    > to only create this 'chassis_system0' object if configured.  I believe
    > the current code change you did does it always, even if the
    > systemd-target is empty.

    I keep getting the feeling that xyz/openbmc_project/chassis_system0 is
    just overloading what /xyz/openbmc_project/chassis0 is intended to do,
    x86-power-control just had that already defined, so we went another
    direction.  I wonder if we just need to make the "Can I do a real AC
    reset" configurable, and have it change the behavior of
    /xyz/openbmc_project/chassis0 in that case.

When I was doing this patch, I proposed the same to keep chassis0 only and
take appropriate actions on different commands. But it was decided to have
a separate interface for complete chassis after several rounds of discussion.
That's why I added this and also updated phosphor-dbus-interface README
file. @andrew any comments here.

    Also, I'll reiterate that a chassis reset really should be going in a
    separate repo/application from x86-power-control.  x86-power-control
    should be focused on managing the host.

I agree.

    >
    > --
    > Patrick Williams

Re: Chassis reset

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

On Wed, Sep 23, 2020 at 12:26:58PM -0700, Ed Tanous wrote:
> On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> >
> > On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
> > >
> > > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
> > > Later one is used for AC reset.
> >
> > Can we do a query to see if 'chassis_system0' exists and use it first
> > and then 'chassis0' if not?
> 
> I don't think it's that simple.  The way the dbus APIs are defined,
> one Redfish chassis needs to call the chassis0 path, the other needs
> to call the chassis_system0 path.  We'd need a way to key off which
> one is which.  I haven't seen any entity-manager configs get checked
> in for a "multinode chassis" entity type, so whatever interface we use
> to describe that will probably be what we need to key off to make that
> path distinction.

In Redfish this would be the system path that maps to chassis_system0
and not the chassis path.  In Redfish today, chassis doesn't do a whole
lot except allow you to power cycle the host.  Most of the control is in
System.

> 
> >
> > I think we need to do some enhancement to x86-power-control though also
> > to only create this 'chassis_system0' object if configured.  I believe
> > the current code change you did does it always, even if the
> > systemd-target is empty.
> 
> I keep getting the feeling that xyz/openbmc_project/chassis_system0 is
> just overloading what /xyz/openbmc_project/chassis0 is intended to do,
> x86-power-control just had that already defined, so we went another
> direction.  I wonder if we just need to make the "Can I do a real AC
> reset" configurable, and have it change the behavior of
> /xyz/openbmc_project/chassis0 in that case.

No, these are not overloading each other.  They are vastly different.

host0 + chassis0 make up the 'BIOS/OS control' and '12V power on rails'
portions of host power control respectively.  chassis_system0 controls the
'12v + 5V standby rails' part of the system.  In my opinion, it should
only be present when a system actually allows manipulation of the
standby power, but that isn't how it is currently implemented.

> Also, I'll reiterate that a chassis reset really should be going in a
> separate repo/application from x86-power-control.  x86-power-control
> should be focused on managing the host.

No disagreement from me; that was my recommendation originally.  But,
the current implementation landed there and was accepted by the
maintainer.  I don't honestly think that matters much at a "how should
Redfish APIs map to these dbus objects" perspective though, which is the
current discussion.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Chassis reset

[Ed Tanous]

On Wed, Sep 23, 2020 at 1:21 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Wed, Sep 23, 2020 at 12:26:58PM -0700, Ed Tanous wrote:
> > On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> > >
> > > On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
> > > >
> > > > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
> > > > Later one is used for AC reset.
> > >
> > > Can we do a query to see if 'chassis_system0' exists and use it first
> > > and then 'chassis0' if not?
> >
> > I don't think it's that simple.  The way the dbus APIs are defined,
> > one Redfish chassis needs to call the chassis0 path, the other needs
> > to call the chassis_system0 path.  We'd need a way to key off which
> > one is which.  I haven't seen any entity-manager configs get checked
> > in for a "multinode chassis" entity type, so whatever interface we use
> > to describe that will probably be what we need to key off to make that
> > path distinction.
>
> In Redfish this would be the system path that maps to chassis_system0
> and not the chassis path.  In Redfish today, chassis doesn't do a whole
> lot except allow you to power cycle the host.  Most of the control is in
> System.

The way Vijay describes it, it's resetting the Chassis (ie, removing
power from the board itself).  The redfish System resource is meant to
model the host, and shouldn't be resetting the BMC.  Maybe I
misunderstood, and this is actually just a host reset?

>
> >
> > >
> > > I think we need to do some enhancement to x86-power-control though also
> > > to only create this 'chassis_system0' object if configured.  I believe
> > > the current code change you did does it always, even if the
> > > systemd-target is empty.
> >
> > I keep getting the feeling that xyz/openbmc_project/chassis_system0 is
> > just overloading what /xyz/openbmc_project/chassis0 is intended to do,
> > x86-power-control just had that already defined, so we went another
> > direction.  I wonder if we just need to make the "Can I do a real AC
> > reset" configurable, and have it change the behavior of
> > /xyz/openbmc_project/chassis0 in that case.
>
> No, these are not overloading each other.  They are vastly different.
>
> host0 + chassis0 make up the 'BIOS/OS control' and '12V power on rails'
> portions of host power control respectively.

Right, I think what I was saying is that we need a mode where chassis0
is freed from host control, and that would simplify the problem a bit,
as the chassis0 api would just do the "right" thing for the platform.
If the platform is capable of an AC reset, do that, if it's not, do a
host reset as x86-power-control currently does.

>  chassis_system0 controls the
> '12v + 5V standby rails' part of the system.  In my opinion, it should
> only be present when a system actually allows manipulation of the
> standby power, but that isn't how it is currently implemented.

Sure, that seems like a fine way to model it, but then we need to come
up with an API to "steer" the Redfish API to the right resource so we
don't break backward compatibility for the things that work today.
That seems harder, and more error prone, but could certainly be
defined.  Whether that shows up as chassis0, or we just redirect to
host0 if chassis0 doesn't exist seems fine to me.

If I can clarify what you're proposing.

host0 controls the host.
chassis0 also controls the host.
chassis_system0 controls the chassis power unit.

>
> > Also, I'll reiterate that a chassis reset really should be going in a
> > separate repo/application from x86-power-control.  x86-power-control
> > should be focused on managing the host.
>
> No disagreement from me; that was my recommendation originally.  But,
> the current implementation landed there and was accepted by the
> maintainer.  I don't honestly think that matters much at a "how should
> Redfish APIs map to these dbus objects" perspective though, which is the
> current discussion.

Fair point, although I suspect that the maintainers platform isn't
capable of this kind of reset.  We can table that discussion for the
moment.

>
> --
> Patrick Williams

Re: Chassis reset

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 5261 bytes --]

On Wed, Sep 23, 2020 at 02:12:10PM -0700, Ed Tanous wrote:
> On Wed, Sep 23, 2020 at 1:21 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> >
> > On Wed, Sep 23, 2020 at 12:26:58PM -0700, Ed Tanous wrote:
> > > On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> > > >
> > > > On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
> > > > >
> > > > > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
> > > > > Later one is used for AC reset.
> > > >
> > > > Can we do a query to see if 'chassis_system0' exists and use it first
> > > > and then 'chassis0' if not?
> > >
> > > I don't think it's that simple.  The way the dbus APIs are defined,
> > > one Redfish chassis needs to call the chassis0 path, the other needs
> > > to call the chassis_system0 path.  We'd need a way to key off which
> > > one is which.  I haven't seen any entity-manager configs get checked
> > > in for a "multinode chassis" entity type, so whatever interface we use
> > > to describe that will probably be what we need to key off to make that
> > > path distinction.
> >
> > In Redfish this would be the system path that maps to chassis_system0
> > and not the chassis path.  In Redfish today, chassis doesn't do a whole
> > lot except allow you to power cycle the host.  Most of the control is in
> > System.
> 
> The way Vijay describes it, it's resetting the Chassis (ie, removing
> power from the board itself). The redfish System resource is meant to
> model the host, and shouldn't be resetting the BMC.  Maybe I
> misunderstood, and this is actually just a host reset?

How do you determine this about Redfish's ComputerSystem?  It seems
really ambiguous.  The only words I can find are this:

| The ComputerSystem schema represents a computer or system instance
| and the software-visible resources, or items within the data plane, such as
| memory, CPU, and other devices that it can access.  Details of those resources
| or subsystems are also linked through this resource.

You understood correctly though.  This is effectively the same as if you
had a PDU and toggled power on the whole device.  Or pulled it from an OCP
rack and plugged it back in.

> > > > I think we need to do some enhancement to x86-power-control though also
> > > > to only create this 'chassis_system0' object if configured.  I believe
> > > > the current code change you did does it always, even if the
> > > > systemd-target is empty.
> > >
> > > I keep getting the feeling that xyz/openbmc_project/chassis_system0 is
> > > just overloading what /xyz/openbmc_project/chassis0 is intended to do,
> > > x86-power-control just had that already defined, so we went another
> > > direction.  I wonder if we just need to make the "Can I do a real AC
> > > reset" configurable, and have it change the behavior of
> > > /xyz/openbmc_project/chassis0 in that case.
> >
> > No, these are not overloading each other.  They are vastly different.
> >
> > host0 + chassis0 make up the 'BIOS/OS control' and '12V power on rails'
> > portions of host power control respectively.
> 
> Right, I think what I was saying is that we need a mode where chassis0
> is freed from host control, and that would simplify the problem a bit,
> as the chassis0 api would just do the "right" thing for the platform.
> If the platform is capable of an AC reset, do that, if it's not, do a
> host reset as x86-power-control currently does.

'chassis0', in dbus, is the DC power control that goes along with booting
the host though.  It is not ever related to AC reset.

> 
> >  chassis_system0 controls the
> > '12v + 5V standby rails' part of the system.  In my opinion, it should
> > only be present when a system actually allows manipulation of the
> > standby power, but that isn't how it is currently implemented.
> 
> Sure, that seems like a fine way to model it, but then we need to come
> up with an API to "steer" the Redfish API to the right resource so we
> don't break backward compatibility for the things that work today.
> That seems harder, and more error prone, but could certainly be
> defined.  Whether that shows up as chassis0, or we just redirect to
> host0 if chassis0 doesn't exist seems fine to me.
> 
> If I can clarify what you're proposing.
> 
> host0 controls the host.
> chassis0 also controls the host.
> chassis_system0 controls the chassis power unit.

The only clarification I'd say here is that 'chassis_system0' controls
the Host + BMC.

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.

With CIM there use to be these Profile documents that showed "the right
way" to fit all these pieces together.  Does that not exist with
Redfish?  How does any external application consume Redfish in a
consistent way?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Chassis reset

[Bills, Jason M]

On 9/23/2020 2:42 PM, Patrick Williams 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.
> 
> With CIM there use to be these Profile documents that showed "the right
> way" to fit all these pieces together.  Does that not exist with
> Redfish?  How does any external application consume Redfish in a
> consistent way?

I'm not sure it helps with the overall consistency question, but for 
OpenBMC, we defined our mapping of Redfish ResetType values to Chassis 
and Host State Transitions on D-Bus, here: 
https://github.com/openbmc/docs/blob/838fa962b73deb1ef7908ee8dfa1203fa5263517/designs/state-management-and-external-interfaces.md#proposed-design.

This is what x86-power-control aspires to match and I think what led to 
creating new D-Bus interfaces for the chassis_system and AC power state 
changes (since we didn't want to break this mapping).

Perhaps we need to separate the Host and Chassis on the Redfish side and 
extend the D-Bus interfaces to support all the needed ResetTypes?
> 

Re: Chassis reset

[Ed Tanous]

On Wed, Sep 23, 2020 at 3:01 PM Bills, Jason M
<jason.m.bills@linux.intel.com> wrote:
>
>
>
> On 9/23/2020 2:42 PM, Patrick Williams 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.
> >
> > With CIM there use to be these Profile documents that showed "the right
> > way" to fit all these pieces together.  Does that not exist with
> > Redfish?  How does any external application consume Redfish in a
> > consistent way?
>
> I'm not sure it helps with the overall consistency question, but for
> OpenBMC, we defined our mapping of Redfish ResetType values to Chassis
> and Host State Transitions on D-Bus, here:
> https://github.com/openbmc/docs/blob/838fa962b73deb1ef7908ee8dfa1203fa5263517/designs/state-management-and-external-interfaces.md#proposed-design.
>
> This is what x86-power-control aspires to match and I think what led to
> creating new D-Bus interfaces for the chassis_system and AC power state
> changes (since we didn't want to break this mapping).

Sounds reasonable, it just makes things slightly more complex for
Redfish, as now there's two things that could be a redfish Chassis
reset.  Not a huge deal.

>
> Perhaps we need to separate the Host and Chassis on the Redfish side and
> extend the D-Bus interfaces to support all the needed ResetTypes?
> >

I'm not following.  There's a Host (ie ComputerSystem) and Chassis in
redfish today.  How would we separate them further?

Re: Chassis reset

[Bills, Jason M]

On 9/23/2020 3:35 PM, Ed Tanous wrote:
> On Wed, Sep 23, 2020 at 3:01 PM Bills, Jason M
> <jason.m.bills@linux.intel.com> wrote:
>>
>>
>>
>> On 9/23/2020 2:42 PM, Patrick Williams 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.
>>>
>>> With CIM there use to be these Profile documents that showed "the right
>>> way" to fit all these pieces together.  Does that not exist with
>>> Redfish?  How does any external application consume Redfish in a
>>> consistent way?
>>
>> I'm not sure it helps with the overall consistency question, but for
>> OpenBMC, we defined our mapping of Redfish ResetType values to Chassis
>> and Host State Transitions on D-Bus, here:
>> https://github.com/openbmc/docs/blob/838fa962b73deb1ef7908ee8dfa1203fa5263517/designs/state-management-and-external-interfaces.md#proposed-design.
>>
>> This is what x86-power-control aspires to match and I think what led to
>> creating new D-Bus interfaces for the chassis_system and AC power state
>> changes (since we didn't want to break this mapping).
> 
> Sounds reasonable, it just makes things slightly more complex for
> Redfish, as now there's two things that could be a redfish Chassis
> reset.  Not a huge deal.
> 
>>
>> Perhaps we need to separate the Host and Chassis on the Redfish side and
>> extend the D-Bus interfaces to support all the needed ResetTypes?
>>>
> 
> I'm not following.  There's a Host (ie ComputerSystem) and Chassis in
> redfish today.  How would we separate them further?
I meant in the table here: 
https://github.com/openbmc/docs/blob/838fa962b73deb1ef7908ee8dfa1203fa5263517/designs/state-management-and-external-interfaces.md#proposed-design.

Extend it to include both Chassis and System ResetType values and map 
them all to the correct State Transition on D-Bus.

> 

Re: Chassis reset

[Ed Tanous]

On Wed, Sep 23, 2020 at 2:42 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Wed, Sep 23, 2020 at 02:12:10PM -0700, Ed Tanous wrote:
> > On Wed, Sep 23, 2020 at 1:21 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> > >
> > > On Wed, Sep 23, 2020 at 12:26:58PM -0700, Ed Tanous wrote:
> > > > On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> > > > >
> > > > > On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
> > > > > >
> > > > > > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
> > > > > > Later one is used for AC reset.
> > > > >
> > > > > Can we do a query to see if 'chassis_system0' exists and use it first
> > > > > and then 'chassis0' if not?
> > > >
> > > > I don't think it's that simple.  The way the dbus APIs are defined,
> > > > one Redfish chassis needs to call the chassis0 path, the other needs
> > > > to call the chassis_system0 path.  We'd need a way to key off which
> > > > one is which.  I haven't seen any entity-manager configs get checked
> > > > in for a "multinode chassis" entity type, so whatever interface we use
> > > > to describe that will probably be what we need to key off to make that
> > > > path distinction.
> > >
> > > In Redfish this would be the system path that maps to chassis_system0
> > > and not the chassis path.  In Redfish today, chassis doesn't do a whole
> > > lot except allow you to power cycle the host.  Most of the control is in
> > > System.
> >
> > The way Vijay describes it, it's resetting the Chassis (ie, removing
> > power from the board itself). The redfish System resource is meant to
> > model the host, and shouldn't be resetting the BMC.  Maybe I
> > misunderstood, and this is actually just a host reset?
>
> How do you determine this about Redfish's ComputerSystem?  It seems
> really ambiguous.  The only words I can find are this:
>
> | The ComputerSystem schema represents a computer or system instance
> | and the software-visible resources, or items within the data plane, such as
> | memory, CPU, and other devices that it can access.  Details of those resources
> | or subsystems are also linked through this resource.

I'm not sure where I got that interpretation;  Maybe by looking at a
lot of Redfish systems?  Maybe from having access to DMTF discussions?
 I'm not really sure.  There's a lot of intent like this that doesn't
get captured in the spec, or is captured in discussions.

In this case, I think the key in the above is "software visible
resources" and "items within the dataplane", of which the power rails
generally are not within the dataplane.  In practice, it tends to
expose a place where you need separation of privileges.  A cloud user
with access to a System node might have permission to power
cycle/reset their System resource, but shouldn't have access to AC
cycle the whole platform/chassis/bmc, hence, the resources need
separated.
There's also the "PoweredBy" links that kinda hint (in a really round
about way) about how the power relationships are supposed to be
organized.


>
> You understood correctly though.  This is effectively the same as if you
> had a PDU and toggled power on the whole device.  Or pulled it from an OCP
> rack and plugged it back in.
>
> > > > > I think we need to do some enhancement to x86-power-control though also
> > > > > to only create this 'chassis_system0' object if configured.  I believe
> > > > > the current code change you did does it always, even if the
> > > > > systemd-target is empty.
> > > >
> > > > I keep getting the feeling that xyz/openbmc_project/chassis_system0 is
> > > > just overloading what /xyz/openbmc_project/chassis0 is intended to do,
> > > > x86-power-control just had that already defined, so we went another
> > > > direction.  I wonder if we just need to make the "Can I do a real AC
> > > > reset" configurable, and have it change the behavior of
> > > > /xyz/openbmc_project/chassis0 in that case.
> > >
> > > No, these are not overloading each other.  They are vastly different.
> > >
> > > host0 + chassis0 make up the 'BIOS/OS control' and '12V power on rails'
> > > portions of host power control respectively.
> >
> > Right, I think what I was saying is that we need a mode where chassis0
> > is freed from host control, and that would simplify the problem a bit,
> > as the chassis0 api would just do the "right" thing for the platform.
> > If the platform is capable of an AC reset, do that, if it's not, do a
> > host reset as x86-power-control currently does.
>
> 'chassis0', in dbus, is the DC power control that goes along with booting
> the host though.  It is not ever related to AC reset.

Gotcha.  On most of my platforms, there's no separation between 12V
rail and host power state.  One cannot exist (for more than a couple
seconds) without the other, so there's no need to independently
control them.

>
> >
> > >  chassis_system0 controls the
> > > '12v + 5V standby rails' part of the system.  In my opinion, it should
> > > only be present when a system actually allows manipulation of the
> > > standby power, but that isn't how it is currently implemented.
> >
> > Sure, that seems like a fine way to model it, but then we need to come
> > up with an API to "steer" the Redfish API to the right resource so we
> > don't break backward compatibility for the things that work today.
> > That seems harder, and more error prone, but could certainly be
> > defined.  Whether that shows up as chassis0, or we just redirect to
> > host0 if chassis0 doesn't exist seems fine to me.
> >
> > If I can clarify what you're proposing.
> >
> > host0 controls the host.
> > chassis0 also controls the host.
> > chassis_system0 controls the chassis power unit.
>
> The only clarification I'd say here is that 'chassis_system0' controls
> the Host + BMC.

If it's really host+bmc, and not a complete reset of the board then
redfish doesn't really have a combined resource that can be used here.
BMC (which maps to the Manager resource) and Host (which maps to the
System resource) are treated as separate things.  If you want to reset
both, I suspect you need to issue 2 redfish actions.

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

>
> With CIM there use to be these Profile documents that showed "the right
> way" to fit all these pieces together.  Does that not exist with
> Redfish?

>:-|   Unfortunately, no, and this gives me no end of heartache.  DMTF has some slightly better resources and discussions like this behind member logins.

>  How does any external application consume Redfish in a
> consistent way?

Very carefully, and ideally with a Redfish profile that defines what
resources your application requires, and tests that verify that your
profile is fully supported, which is a whole other level of
indirection on top of the Redfish spec.

>
> --
> Patrick Williams

Re: Chassis reset

[Vijay Khemka]

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

Re: Chassis reset

[Ed Tanous]

On Wed, Sep 23, 2020 at 6:59 PM Vijay Khemka <vijaykhemka@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.

Re: Chassis reset

[Vijay Khemka]

On 9/23/20, 7:24 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Wed, Sep 23, 2020 at 6:59 PM Vijay Khemka <vijaykhemka@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.

    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? 

Re: Chassis reset

[Ed Tanous]

On Tue, Sep 29, 2020 at 3:14 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/23/20, 7:24 PM, "Ed Tanous" <ed@tanous.net> wrote:
>
>     On Wed, Sep 23, 2020 at 6:59 PM Vijay Khemka <vijaykhemka@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.

Re: Chassis reset

[Vijay Khemka]

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

    On Tue, Sep 29, 2020 at 3:14 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 9/23/20, 7:24 PM, "Ed Tanous" <ed@tanous.net> wrote:
    >
    >     On Wed, Sep 23, 2020 at 6:59 PM Vijay Khemka <vijaykhemka@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.

Re: Chassis reset

[Joseph Reynolds]

On 9/23/20 4:42 PM, Patrick Williams wrote:
> On Wed, Sep 23, 2020 at 02:12:10PM -0700, Ed Tanous wrote:
>> On Wed, Sep 23, 2020 at 1:21 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>>> On Wed, Sep 23, 2020 at 12:26:58PM -0700, Ed Tanous wrote:
>>>> On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>>>>> On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
>>>>>> Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
>>>>>> Later one is used for AC reset.
>>>>> Can we do a query to see if 'chassis_system0' exists and use it first
>>>>> and then 'chassis0' if not?
>>>>
...snip...
> With CIM there use to be these Profile documents that showed "the right
> way" to fit all these pieces together.  Does that not exist with
> Redfish?  How does any external application consume Redfish in a
> consistent way?

I don't know much about this area.  I understand Redfish is always 
looking for more system configurations:
https://redfish.dmtf.org/redfish/mockups/v1

Otherwise, you could post this question here:
https://redfishforum.com/board/1/protocol-specification

- Joseph

Re: Chassis reset

[Vijay Khemka]

On 9/23/20, 2:12 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Wed, Sep 23, 2020 at 1:21 PM Patrick Williams <patrick@stwcx.xyz> wrote:
    >
    > On Wed, Sep 23, 2020 at 12:26:58PM -0700, Ed Tanous wrote:
    > > On Wed, Sep 23, 2020 at 12:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
    > > >
    > > > On Wed, Sep 23, 2020 at 05:45:51AM +0000, Vijay Khemka wrote:
    > > > >
    > > > > Yes I have 2 chassis instance xyz/openbmc_project/chassis0 and xyz/openbmc_project/chassis_system0.
    > > > > Later one is used for AC reset.
    > > >
    > > > Can we do a query to see if 'chassis_system0' exists and use it first
    > > > and then 'chassis0' if not?
    > >
    > > I don't think it's that simple.  The way the dbus APIs are defined,
    > > one Redfish chassis needs to call the chassis0 path, the other needs
    > > to call the chassis_system0 path.  We'd need a way to key off which
    > > one is which.  I haven't seen any entity-manager configs get checked
    > > in for a "multinode chassis" entity type, so whatever interface we use
    > > to describe that will probably be what we need to key off to make that
    > > path distinction.
    >
    > In Redfish this would be the system path that maps to chassis_system0
    > and not the chassis path.  In Redfish today, chassis doesn't do a whole
    > lot except allow you to power cycle the host.  Most of the control is in
    > System.

    The way Vijay describes it, it's resetting the Chassis (ie, removing
    power from the board itself).  The redfish System resource is meant to
    model the host, and shouldn't be resetting the BMC.  Maybe I
    misunderstood, and this is actually just a host reset?

Yes it is removing power from whole system and restoring back. It includes
Everything in the system like host, bmc and other devices on board. We call
This as sled_cycle like you pull out chassis from rack and push it back.

    >  chassis_system0 controls the
    > '12v + 5V standby rails' part of the system.  In my opinion, it should
    > only be present when a system actually allows manipulation of the
    > standby power, but that isn't how it is currently implemented.

    Sure, that seems like a fine way to model it, but then we need to come
    up with an API to "steer" the Redfish API to the right resource so we
    don't break backward compatibility for the things that work today.
    That seems harder, and more error prone, but could certainly be
    defined.  Whether that shows up as chassis0, or we just redirect to
    host0 if chassis0 doesn't exist seems fine to me.

    If I can clarify what you're proposing.

    host0 controls the host.
    chassis0 also controls the host.
    chassis_system0 controls the chassis power unit.

Controls whole system