From: Vijay Khemka <vijaykhemka@fb.com>
To: Ed Tanous <ed@tanous.net>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Chassis reset
Date: Wed, 23 Sep 2020 05:45:51 +0000 [thread overview]
Message-ID: <F46D657F-D4DA-49BD-B78D-CDD420768728@fb.com> (raw)
In-Reply-To: <CACWQX83GJ9V9--5WGmVjvacYnw2=fr7URhqOcwkSq4C8GpFoiQ@mail.gmail.com>
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
>
next prev parent reply other threads:[~2020-09-23 5:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 19:50 Chassis reset Vijay Khemka
2020-09-18 21:38 ` Ed Tanous
2020-09-18 23:28 ` Vijay Khemka
2020-09-19 0:17 ` Ed Tanous
2020-09-22 19:16 ` Vijay Khemka
2020-09-23 0:17 ` Ed Tanous
2020-09-23 5:45 ` Vijay Khemka [this message]
2020-09-23 19:10 ` Patrick Williams
2020-09-23 19:26 ` Ed Tanous
2020-09-23 19:55 ` Vijay Khemka
2020-09-23 20:21 ` Patrick Williams
2020-09-23 21:12 ` Ed Tanous
2020-09-23 21:42 ` Patrick Williams
2020-09-23 21:59 ` Bills, Jason M
2020-09-23 22:35 ` Ed Tanous
2020-09-23 23:29 ` Bills, Jason M
2020-09-23 22:31 ` Ed Tanous
2020-09-24 1:59 ` Vijay Khemka
2020-09-24 2:24 ` Ed Tanous
2020-09-29 22:13 ` Vijay Khemka
2020-09-29 22:22 ` Ed Tanous
2020-09-29 23:29 ` Vijay Khemka
2020-09-24 3:08 ` Joseph Reynolds
2020-09-24 1:48 ` Vijay Khemka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F46D657F-D4DA-49BD-B78D-CDD420768728@fb.com \
--to=vijaykhemka@fb.com \
--cc=ed@tanous.net \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).