Re: D-Bus interface to provide data to entity manager

["Thomaiyar, Richard Marian" <richard.marian.thomaiyar@linux.intel.com>]

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

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 ?


regards,

Richard


Say, we want to expose Manufacturer Name, then it can be produced by 
PLDM FRU application, IPMI Fru based application or even any proprietary 
application and consumed by applications like Redfish / any other 
proprietary one. In this way applications can get the data of what ever 
it is required. I don't find any data which is different in terms of 
PLDM FRU / IPMI FRU (ofcourse OEM fields will be there, but that can't 
be unique), but we need to implement things in common form though.

Say, ChassisType in IPMI FRU is single byte field, whereas in PLDM FRU 
it will be of string. But we need to represent the same in well 
established form (say SMBIOS System /Chassis Type enums). i.e. Producers 
(IPMI FRU must change it from one byte type to enum), and PLDM FRU from 
string to proper enum. Redfish will use this one and accordingly map it 
to the schema


On 5/26/2020 6:26 PM, Deepak Kodihalli wrote:
> On 19/05/20 9:10 am, Deepak Kodihalli wrote:
>> Hi,
>>
>> IBM systems have a requirement to consume FRU information sent down 
>> via the host firmware and then relay that onto D-Bus (and then onto 
>> Redfish). The host firmware will send down FRU information using PLDM.
>>
>> We wanted to use entity manager to enable transforming the PLDM FRU 
>> data to D-Bus properties that fall under D-Bus inventory interfaces 
>> such as the xyz.openbmc_project.Inventory.Decorator.Asset interface. 
>> I have an update to the PLDM design doc to capture this flow [1], and 
>> some D-Bus interfaces [2] proposed on Gerrit. Would appreciate 
>> feedback on the same. The high level idea is that the pldm daemon 
>> will host raw PLDM FRU information on D-Bus, and via JSON configs, 
>> entity manager can convert those to D-Bus inventory objects (which 
>> then can be found by bmcweb).
>>
>>  From an entity manager perspective, I had few questions :
>> - I see there is provision for persistence, but it looks like 
>> applying the persisted information works only if "D-Bus probes" 
>> succeed. We have a requirement to make the host-sent inventory 
>> information available even when the host is powered off. Now if the 
>> host has sent this, then powers off, and then BMC reboots, the BMC 
>> will no longer have the raw PLDM FRU information on D-Bus and hence 
>> the entity manager probe on the same will fail. Question is, can the 
>> probes be made optional when reading the persisted config (system.json)?
>>
>> - How are hierarchical relationships between FRUs supposed to be 
>> represented? Is that based on D-Bus pathnames? Or making use of 
>> something like the D-Bus Associations interface? Any thoughts on how 
>> representing such parent-child relation can be achieved via entity 
>> manager configs?
>>
>> [1] https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/32532/
>> [2] 
>> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/32533/ 
>>
>>
>> Thanks,
>> Deepak
>>
>
> I've got some feedback on the proposal above, which is primarily 
> directed at/impacts how the PLDM daemon provides FRU information to 
> the entity manager daemon. Wanted to discuss the same here.
>
> Very briefly, the proposal was :
> a) The PLDM daemon will parse PLDM FRU format data and host the same 
> on D-Bus as a set of PLDM FRU properties (similar to how the FruDevice 
> daemon hosts properties under xyz.openbmc_project.FruDevice).
> b) Apply EM system/board specific configurations on a) to be able to 
> create specific inventory D-Bus objects (this is how EM works today).
>
>
> To do a) above, there are 3 options:
>
> 1) Propose a D-Bus interface in phosphor-dbus-interfaces. This was [2] 
> in my original email above. The concern raised by Patrick here is that 
> this interface is very specific to a protocol (PLDM in this case), 
> whereas the phosphor D-Bus interfaces are mostly abstract and protocol 
> agnostic.
>
> In my opinion, PLDM is also a data model, so PLDM specific D-Bus 
> interfaces can enable two apps that are PLDM aware (for eg a PLDM 
> requester app talking to the PLDM daemon) to talk to each other. I do 
> see other protocol specific D-Bus interfaces as well (for eg related 
> to SMBIOS). So I don't really understand the concern. The protocol 
> specific interfaces do not preclude other abstract interfaces.
>
>
>
> 2) Propose a generic/abstract 'FRU properties' kind of D-Bus 
> interface. This is something that both the PLDM daemon and FRU device 
> daemon could use to host FRU information on D-Bus, and to provide the 
> same as an intermediate FRU format data to apps like EM. The 
> suggestion on the docs commit above [2] was to have an interface like 
> {Enum[Protocol], array[byte]}. I think instead this could be a 
> dict[string, variant[string, int64]], for a FRU property to value 
> mapping.
>
> While this sounds interesting, are the maintainers of EM and FruDevice 
> interested in such an interface? Based on how this interface is 
> designed, it might imply changes to FruDevice and Entity Manager. I 
> might be interested in chasing this based on the feedback received, 
> and if this will really have users other than the PLDM daemon.
>
>
>
> 3) If everyone thinks option 1 is a bad idea, and if the interest in 
> option 2 is limited, I could do this based on how the FruDevice daemon 
> and EM interact today, which is based on kind of a private D-Bus 
> interface between the two apps. I don't think the Fru device daemon is 
> tied up to EM though, it could even be in its own repository.
>
>
> Thanks,
> Deepak

[-- Attachment #2: Type: text/html, Size: 11285 bytes --]