All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 18 Sep 2020 23:28:49 +0000	[thread overview]
Message-ID: <9EC0D657-2D58-4544-BA9E-65D3C4148A81@fb.com> (raw)
In-Reply-To: <CACWQX802HpRT20Zj2YFEnVE7XXBOJXx66-8B1E7TEZdCNwPbsQ@mail.gmail.com>



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


  reply	other threads:[~2020-09-18 23:28 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 [this message]
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
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=9EC0D657-2D58-4544-BA9E-65D3C4148A81@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.