System Firmware states on D-Bus

System Firmware states on D-Bus

[Andrew Geissler]

I sent an email[1] out a while ago about mapping Redfish Host states to
PLDM Boot values.

Now that we have that design moving, the next question is whether we want
to try and map these to our current IPMI-based state sensors[2]
(OperatingSystemState and BootProgress)? These are currently displayed when
a user does a "obmcutil state" and I see a few other repositories reference
them for boot status. The openbmc-test suite also uses them fairly extensively
to verify different boot tests.

If we want to maintain backwards compatibility then we should map the new PLDM
based boot progress to these two. Mapping them does not seem too difficult.
I could have phosphor-host-state-manager (which hosts these D-Bus properties)
listen for changes to the PLDM property and update the two properties
appropriately. This assumes a system where the system firmware is only
IPMI or PLDM (not both) since they would not play all that well together.

From a Redfish API perspective, it will just directly look at the PLDM
property.

Thoughts?

[1]: https://lists.ozlabs.org/pipermail/openbmc/2020-February/020417.html
[2]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Progress.interface.yaml
     https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml

Re: System Firmware states on D-Bus

[Thomaiyar, Richard Marian]

Prefer D-Bus conveying details in finer / better manner, rather than 
tying it towards any user facing application like Redfish / IPMI.

i.e. We can define all possible values in D-Bus interface, so that any 
application (common / oem), can try to use the value, rather than value 
not being available in D-Bus. Redfish / IPMI can have conversion logic 
to group the values as per the need.

Regards,

Richard

On 2/24/2020 10:57 PM, Andrew Geissler wrote:
> I sent an email[1] out a while ago about mapping Redfish Host states to
> PLDM Boot values.
>
> Now that we have that design moving, the next question is whether we want
> to try and map these to our current IPMI-based state sensors[2]
> (OperatingSystemState and BootProgress)? These are currently displayed when
> a user does a "obmcutil state" and I see a few other repositories reference
> them for boot status. The openbmc-test suite also uses them fairly extensively
> to verify different boot tests.
>
> If we want to maintain backwards compatibility then we should map the new PLDM
> based boot progress to these two. Mapping them does not seem too difficult.
> I could have phosphor-host-state-manager (which hosts these D-Bus properties)
> listen for changes to the PLDM property and update the two properties
> appropriately. This assumes a system where the system firmware is only
> IPMI or PLDM (not both) since they would not play all that well together.
>
>  From a Redfish API perspective, it will just directly look at the PLDM
> property.
>
> Thoughts?
>
> [1]: https://lists.ozlabs.org/pipermail/openbmc/2020-February/020417.html
> [2]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Progress.interface.yaml
>       https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml

Re: System Firmware states on D-Bus

[Patrick Williams]

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

On Tue, Feb 25, 2020 at 07:47:42PM +0530, Thomaiyar, Richard Marian wrote:
> Prefer D-Bus conveying details in finer / better manner, rather than tying
> it towards any user facing application like Redfish / IPMI.

I agree with this.

Define internal D-Bus information with the most we have available and
let external interfaces map this to their constrained subset as
necessary.  There is no reason to limit our own abilities because of the
management interface du-jour.

-- 
Patrick Williams

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

Re: System Firmware states on D-Bus

[Andrew Geissler]

> On Feb 25, 2020, at 10:04 AM, Patrick Williams <patrick@stwcx.xyz> wrote:
> 
> On Tue, Feb 25, 2020 at 07:47:42PM +0530, Thomaiyar, Richard Marian wrote:
>> Prefer D-Bus conveying details in finer / better manner, rather than tying
>> it towards any user facing application like Redfish / IPMI.
> 
> I agree with this.
> 
> Define internal D-Bus information with the most we have available and
> let external interfaces map this to their constrained subset as
> necessary.  There is no reason to limit our own abilities because of the
> management interface du-jour.

Yep, no arguments from me here. The PLDM sensor(or whatever
the right term for it is) will support all defined values sent to it
by the system firmware.

bmcweb will translate what it can when responding to a Redfish
API query for the host state.

I’m thinking I’ll have phosphor-state-manager translate whatever
it can into the OperatingSystemState and BootProgress D-Bus
properties.

> 
> -- 
> Patrick Williams