D-Bus interface to provide data to entity manager

[Thomaiyar, Richard Marian]

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 EM?
>
[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.

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).

(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).

Regards,

Richard

> 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.
>
> Thanks,
> Deepak
>
>>
>> regards,
>>
>> Richard