phosphor-state-manager enhancements

Wed Dec 4 05:40:56 AEDT 2019

> On Nov 24, 2019, at 8:34 PM, CS20 CHLi30 <CHLI30 at nuvoton.com> wrote:
> 
> Hi Andrew,
> 
> Regarding of Host state about BootProgress and OperatingSystemState, I didn't find any code on OpenBMC github to update these states according boot progress or OS state.
> However, I only can find the initialize state about these states when Host state is OFF in phosphor-state-manager as below:

This requires you setup the inband IPMI sensors (something like
https://github.com/openbmc/meta-ibm/blob/master/meta-witherspoon/recipes-phosphor/configuration/acx22-yaml-config/acx22-ipmi-sensors-mrw.yaml#L123)
and then the host firmware uses inband IPMI to set them to the appropriate state
as they boot. This sounds very familiar with what you did with postd.

> 
> void Host::sysStateChange(sdbusplus::message::message& msg)
> {
> ........
>    log<level::INFO>("Received signal that host is off");
>    this->currentHostState(server::Host::HostState::Off);
>    this->bootProgress(bootprogress::Progress::ProgressStages::Unspecified);
>    this->operatingSystemState(osstatus::Status::OSStatus::Inactive);
> }
> 
> Thus, we try to update those states according BIOS POST CODE in phosphor-host-postd.
> And we also design a JSON file for customer to specific their BIOS POST CODE according their Host motherboard.
> Then customer can know the boot progress state when Host power ON for sure.
> But, OSStatus state I just can specific Standby and Inactive, due to I didn't know how to specific detail OS state according what's condition.
> 
> I don't know whether is right place to update these states in phosphor-host-postd, I also think to implement this in phosphor-state-manager before, but might be change original design.

phosphor-state-manager just hosts the sensor. I think as long as there’s no
conflict with the IPMI based stuff above then it is good to do this in
phosphor-host-postd.

> Could you help me to check whether those states can be updated according customer's Host MB in phosphor-state-manger? Or just implement in phosphor-host-postd as we provided?
> We just finish rough version now and we will share the code in our github (https://github.com/Nuvoton-Israel/openbmc <https://github.com/Nuvoton-Israel/openbmc>) for you refer it later.
> If you have any suggestion, please don't hesitate to tell me. Thank you.
> 
> Sincerely,
> Tim Lee
> 
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+chli30=nuvoton.com at lists.ozlabs.org <mailto:openbmc-bounces+chli30=nuvoton.com at lists.ozlabs.org>] On Behalf Of Andrew Geissler
> Sent: Saturday, November 16, 2019 4:40 AM
> To: apparao.puli at linux.intel.com <mailto:apparao.puli at linux.intel.com>; jason.m.bills at linux.intel.com <mailto:jason.m.bills at linux.intel.com>; OpenBMC Maillist <openbmc at lists.ozlabs.org <mailto:openbmc at lists.ozlabs.org>>
> Subject: phosphor-state-manager enhancements
> 
> Since the creation of phosphor-state-manager and its representation of the different bmc/chassis/host states, there has been a steady influx of requests to provide more state and actions to these objects.
> 
> I'm starting to look into how best do this. There have been a few different code and doc commits in this area, but they all seem to get stuck because they break with the original design points of phosphor-state-manager. I'd like to fix that. See [1] below for different requests I know of.
> 
> My concern is that if we don't address these additional state needs within phosphor-state-manager, we'll just do it elsewhere, which causes redundancy and makes it more challenging to share code.
> 
> The original design of phosphor-state-manager was to keep it super simple and basically make it a wrapper around systemd targets. There was a large focus on keeping the different objects (BMC, Chassis, Host) separate to ensure some day when multiple BMC's, Chassis's, or Hosts are added to a system, it all would just work.
> 
> There are definitely some merits to this design:
> - It ensures anyone can insert their services into the appropriate systemd
>  targets without any phosphor-state-manager code changes required
> - A direct mapping of phosphor-state-manager state to systemd target keeps the
>  code very simple
> 
> Some drawbacks to this design though:
> - Our systemd target design is complicated [2]. There are lots of targets that
>  need to be understood to get services in the right spots.
> - It provides very limited state information. BMC is ready or not ready, chassis
>  is on or off, host is running or off.
> - It provides limited control. Reboot the BMC, turn chassis on or off, start,
>  stop, or reboot the host.
> 
> The design was that external entities could do the more advanced logic. Want your system to hard power off, use the chassis object. Want to power cycle your chassis, turn it off, wait, then turn it on. Want to know if it's powering on, look at the requested state and current state and do the logic yourself.
> 
> So what am I thinking? I'm thinking that we should at least represent a subset of Redfish states. Here's the full list:
> 
> "Absent": "This function or Resource is either not present or detected.",
> "Deferring": "The element does not process any commands but queues new  requests.",
> "Disabled": "This function or Resource is disabled.",
> "Enabled": "This function or Resource is enabled.",
> "InTest": "This function or Resource is undergoing testing.",
> "Quiesced": "The element is enabled but only processes a restricted set of  commands.",
> "StandbyOffline": "This function or Resource is enabled but awaits an external  action to activate it.",
> "StandbySpare": "This function or Resource is part of a redundancy set and  awaits a failover or other external action to activate it.",
> "Starting": "This function or Resource is starting.",
> "UnavailableOffline": "This function or Resource is present but cannot be  used.",
> "Updating": "The element is updating and may be unavailable or degraded."
> 
> Starting -> Could apply to Chassis and Host when they are powering on / starting InTest -> Could apply to when a host is taking an NMI and collecting debug Updating -> Could apply to BMC and Host when a firmware update is in progress
> 
> There is actually a PowerState associated with the ComputerSystem we could enhance the chassis with as well (PoweringOn, PoweringOff)
> 
> And also, some Redfish ComputerSystem.Reset operations we don't currently
> support:
> - ForceOff, ForceRestart, PowerCycle
> Note we do "support" these but only via multiple operations.
> 
> Should we try to capture more of the host states? Right now we capture those in the BootProgress and OperatingSystemState sensors.
> 
> So anyways, before I went to far I figured I'd get a note out to see if others have thoughts. How ingrained are the current states? Will adding new one's have a large impact on other software?
> 
> Thanks,
> Andrew
> 
> [1]
> # add firmware update state to BMC
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_phosphor-2Ddbus-2Dinterfaces_-2B_26867&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=w7KqqRbUGx9O-RRNQq88tlIqLK8zTeWDhd0bdHENFfM&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_phosphor-2Ddbus-2Dinterfaces_-2B_26867&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=w7KqqRbUGx9O-RRNQq88tlIqLK8zTeWDhd0bdHENFfM&e=>
> 
> # Add PowerCycle and Reset to Chassis
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_phosphor-2Ddbus-2Dinterfaces_-2B_22270&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=mbMb7E_sSUWc011oMs8qSDg4Hc8EPATv6wxib2N3_vA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_phosphor-2Ddbus-2Dinterfaces_-2B_22270&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=mbMb7E_sSUWc011oMs8qSDg4Hc8EPATv6wxib2N3_vA&e=>
> 
> # Additional host states (Started)
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_docs_-2B_22461&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=4MH0PcYK-XwSnT9GP5nGcfiBGSI5OskjVoabI4YU2qY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_docs_-2B_22461&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=4MH0PcYK-XwSnT9GP5nGcfiBGSI5OskjVoabI4YU2qY&e=>
> 
> [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openbmc_phosphor-2Dstate-2Dmanager_blob_master_README.md&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=LCKvfbVMnsZXf9QXm3Sj_jwIyZ4sA-iMR5V6h5cgx1Y&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openbmc_phosphor-2Dstate-2Dmanager_blob_master_README.md&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=LCKvfbVMnsZXf9QXm3Sj_jwIyZ4sA-iMR5V6h5cgx1Y&e=>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openbmc_docs_blob_master_architecture_openbmc-2Dsystemd.md&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=heBYleM5zEoXveGImF4HosBWu9desGmmN8D-JJ9czx4&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openbmc_docs_blob_master_architecture_openbmc-2Dsystemd.md&d=DwIBaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=_vvS1tH9U_15yp1--_mdcWxVamV74LY4Xz5Zy4-7UIo&m=YXb9PBIGgZ166eMzmnoOfWmfSnevY37ePCfhnqsnZt4&s=heBYleM5zEoXveGImF4HosBWu9desGmmN8D-JJ9czx4&e=>
> ________________________________
> ________________________________
> The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191203/488d78dd/attachment-0001.htm>