D-Bus interface to provide data to entity manager
Thomaiyar, Richard Marian
richard.marian.thomaiyar at linux.intel.com
Thu May 28 03:19:38 AEST 2020
On 5/27/2020 9:16 PM, Deepak Kodihalli wrote:
> On 27/05/20 8:55 pm, Thomaiyar, Richard Marian wrote:
>> On 5/27/2020 7:28 PM, Deepak Kodihalli wrote:
>>> On 27/05/20 7:20 pm, Thomaiyar, Richard Marian wrote:
>>>> I always view D-Bus interface as a specification / API which can
>>>> work with different producers / consumers (correct me, if that's
>>>> not what we intend with D-Bus interface here). Problem with Option
>>>> 1 is, it will end up in having multiple producers exposing
>>>> different interface, and thereby consumers(user interface facing
>>>> applications) of D-Bus must be aware about all the D-Bus interfaces
>>>> and always requires change.
>>>> Consider, we want to expose ChassisType, then irrespective of PLDM
>>>> FRU / IPMI FRU / Proprietary FRU, Consumer applications must read
>>>> it in the same manner. Having different interface / property types,
>>>> requires update in both the end. PLDM FRU / IPMI FRU can be in
>>>> common form (except few nit's /OEM's). We need to make sure it is
>>>> represented in that angle. As of today phosphor-dbus-interfaces
>>>> doesn't have FRU interface, but it has inventory related interfaces
>>>> (exposed by Entity-Manager), which is what Redfish uses (i.e.
>>>> Indirectly the FruDevice exposed interface is hidden by
>>>> Entity-manager, and inventory interface exposed by entity-manager
>>>> is used).
>>>> As of today, entity-manager doesn't add Inventory interface
>>>> automatically for Add-on cards (which doesn't have any json
>>>> configuration), but needs exposure (say PLDM based Add on card
>>>> devices will be of this type), but shouldn't be hard to add it anyway.
>>>> Now the question is do we want to expose FRU as a separate
>>>> interafce to be used in User facing application, or shall we just
>>>> use Inventory based interface itself ?If inventory itself can be
>>>> used, then let's go ahead and add more fields to those if missing
>>>> anything / correct the same accordingly.
>>>> James, Deepak, Patrick - your thoughts ?
>>> I guess there is a difference between FRU and inventory. If
>>> inventory interfaces could be used directly, why wouldn't the
>>> FruDevice or PLDM apps directly host inventory objects, why even use
>> [Richard]: Inventory.Decorator is used in Redfish. i.e. Today
>> Frudevice & it's interface exposed is consumed by Entity-Manager
>> alone & Entity manager exposes all the needed configuration along
>> with Inventory.Decorator.Asset interface. (As you stated, inventory
>> does more than what FRU has to expose, but i am trying to see can we
>> use Inventory.Decorator itself to expose these needed FRU
>> information?). James F ? (Maintainer of both EM & bmcweb)
>> Current Behavior:
>> Say - Baseboard fru information is exposed by FruDevice, and Entity
>> Manager exposes the sensor or any configuration required for platform
>> A or Platform B (based on fru device data). Entity-manager also
>> expose Inventory interface which hides the manufacturer name exposed
>> by FRU, but exposes the it as Manufacturer in the Inventory interface
>> and Redfish uses this).
>> In case of exposing the PLDM FRU
>> Option 1:
>> If we need to rely on PLDM FRU, then Entity-Manager will probe the
>> FruDevice data exposed by PLDM FRU daemon, and expose the inventory
>> (both for sensor configuration and decorator Asset), we don't change
>> any upper layer application. We can follow the same design for the
>> PLDM FRU daemon.
> Yes, the question remains as to what kind of D-Bus interface does the
> PLDM daemon use. Make it's own, similar to
> xyz.openbmc_project.FruDevice (which the FruDevice daemon makes), or
> use a PLDM specific one (for which I have a patch on Gerrit), or use a
> common interface that can be used by both FruDevice and PLDM.
[Richard]: If we are choosing this option, then we can use the existing
Frudevice interface and use the PRODUCT_XYZ which is currently exposed.
Almost all the PLDM Fru content will match the IPMI FRU, except few like
SKU, version, description, Engineering_change_level & Vendor IANA (which
we can expose as new properties in the same interface) ??
i.e. PLDM PartNumber is nothing but PRODUCT_PART_NUMBER in IPMI Fru etc.
>> Note: Currently, it doesn't have a mechanism to expose all the FRU
>> devices as Inventory.Decorator interface automatically when there is
>> no json configuration for it in EM. This needs to be fixed (say for
>> PLDM based Add-on card).
>> Option 2:
>> Define new FRU interface (common for both PLDM, IPMI etc.), similar
>> to inventory and this itself will be used by both Entity-manager &
>> user level interface application (say Redfish).
> I didn't intend this to be something that describes inventory, but
> rather a common (to PLDM, FruDevice, other apps) alternative to
> xyz.openbmc_project.FruDevice, which is what the FruDevice daemon
> hosts on D-Bus today. EM can continue to make objects that implement
> xyz.openbmc_project.Inventory.Foo interfaces, since they represent
> inventory information.
[Richard]: Yes, there will be 2 daemons for FRU Devices, 1.
xyz.openbmc_project.FruDevice and 2. xyz.openbmc_project.PLDM.FruDevice,
both exposing xyz.openbmc_project.FruDevice which will be consumed by
Entity-manager and accordingly expose the Inventory.Decorator.Asset for
use in Redfish.
>> (Problem with option 2 is it requires changes in Currenr behavior,
>> and redfish etc, may need to update it's code to use the common FRU
>> interface rather than inventory.Decorator).
>>> I believe these apps (FruDevice, PLDM daemon) operate at a per FRU
>>> level, and rely on something like EM to make one or more inventory
>>> objects based on the FRU data. So that was my option 2, a generic
>>> FRU properties interface. I'm just not sure at the moment the
>>> impact/interest of doing something like that and then aligning
>>> FruDevice and EM to the same.
More information about the openbmc