Processing PLDM FRU information with entity manager

Processing PLDM FRU information with entity manager

[Deepak Kodihalli]

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

Re: Processing PLDM FRU information with entity manager

[Brad Bishop]

On Tue, 2020-05-19 at 09:10 +0530, Deepak Kodihalli wrote:

Hi Deepak

> I see there is provision for persistence, but it looks like
> applying the persisted information works only if "D-Bus probes"
> succeed.

This prompted me to take a closer look - as far as I can tell
system.json is for debugging purposes only.  Maybe James could confirm.

Given this we should probably have an application layer other than
entity-manager layer be responsible for maintaining the PLDM FRU
objects on the DBus at the correct time. 

> the BMC will no longer have the raw PLDM FRU information on D-Bus

I think we have to fix this.  It doesn't feel right that the PLDM FRU
DBus objects come and go off the bus as the system is powered on/off.

> 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?

I'm also hoping James or Richard will let us know what their thoughts
are for doing this.

-brad

Re: Processing PLDM FRU information with entity manager

[James Feist]

On 5/20/2020 9:28 AM, Brad Bishop wrote:
> On Tue, 2020-05-19 at 09:10 +0530, Deepak Kodihalli wrote:
> 
> Hi Deepak
> 
>> I see there is provision for persistence, but it looks like
>> applying the persisted information works only if "D-Bus probes"
>> succeed.

There is a PowerState parameter that tells when it can be detected that 
can be used. PowerState="On" things only get removed if detected once 
power is back online.

> 
> This prompted me to take a closer look - as far as I can tell
> system.json is for debugging purposes only.  Maybe James could confirm.

No, the modifiable things are persisted there. Such as thresholds.

> 
> Given this we should probably have an application layer other than
> entity-manager layer be responsible for maintaining the PLDM FRU
> objects on the DBus at the correct time.
> 
>> the BMC will no longer have the raw PLDM FRU information on D-Bus
> 
> I think we have to fix this.  It doesn't feel right that the PLDM FRU
> DBus objects come and go off the bus as the system is powered on/off.
> 
>> 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?
> 
> I'm also hoping James or Richard will let us know what their thoughts
> are for doing this.

I need a better example. FRUs are independent things, so there is no 
hierarchy. Are you talking about Chassis level things? Those are just 
handled by having the right type.

> 
> -brad
> 

Re: Processing PLDM FRU information with entity manager

[Brad Bishop]

On Wed, 2020-05-20 at 09:56 -0700, James Feist wrote:

> I need a better example. FRUs are independent things, so there is no 
> hierarchy.

A drive plugs into a riser which plugs into the motherboard.  Isn't
that a hierarchy?

Re: Processing PLDM FRU information with entity manager

[James Feist]

On 5/20/2020 10:35 AM, Brad Bishop wrote:
> On Wed, 2020-05-20 at 09:56 -0700, James Feist wrote:
> 
>> I need a better example. FRUs are independent things, so there is no
>> hierarchy.
> 
> A drive plugs into a riser which plugs into the motherboard.  Isn't
> that a hierarchy?
> 

For a FRU, no. FRUs are independent items. For inventory, yes. Assuming 
you mean inventory then? If so, then the paths do not have any hierarchy 
today. I assume it might be possible by creating an i2c device tree of 
sorts and mapping back what bus is which item.

D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager)

[Deepak Kodihalli]

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

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

[Thomaiyar, Richard Marian]

[-- 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 --]

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

[Deepak Kodihalli]

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?

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

Re: 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

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

[Deepak Kodihalli]

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

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.

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


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

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

[Thomaiyar, Richard Marian]

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

Regards,

Richard

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

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

[Patrick Williams]

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

I already responded with my overall design preference but had one point
in the chain I wanted to discuss a bit more.

On Wed, May 27, 2020 at 10:49:38PM +0530, Thomaiyar, Richard Marian wrote:
> 
> [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.

The current FruDevice interface is effectively a private dbus API
between EM and `fru-device` (which is also in the EM repo anyhow) and it
doesn't follow either our dbus practices nor widely accepted ones.  Here
are a few reasons:

    - FruDevice instances do not have the same properties.  Two
      different IPMI FRU types create a different set of properties, so
      you end up with dbus objects with a variety of interface layouts.

    - The properties exposed are not documented and differ stylistically
      from our existing, documented dbus objects.

Right now, if we need to implement another FruDevice provider, such as
will likely happen as Facebook implements our multi-host system, we have
to reverse engineer the code in `fru-device`.  Ideally this would be
refactored into a set of documented dbus interfaces under
`Inventory/Source/IPMI` (or some equally reasonable name) so others
could implement as needed.

-- 
Patrick Williams

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

Re: D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager)

[Patrick Williams]

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

On Tue, May 26, 2020 at 06:26:27PM +0530, Deepak Kodihalli wrote:
> On 19/05/20 9:10 am, Deepak Kodihalli wrote:
> 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.

After thinking about it for a bit, I think this is my preference with
the design caveat that these are only consumed by processes which are
"FRU-to-Inventory" transformers.  I would suggest putting these
interfaces under the 'Inventory/' namespace somewhere to hopefully make
this clearer.

We have two implementations of these "FRU-to-Inventory" transformers: EM
and PIM.  Both of them have a form of dbus backdoor in order to get the
information they need to create the Inventory objects they host.  PIM uses
`Inventory/Manager`[1] and EM uses an undocumented `FruDevice` interface
between it and 'fru-device'.  Both of these implementations do
processing on the data they get (though, very minimal in the case of
PIM) and create `Inventory/Item`s as a result.

What I am worried about, and Richard seconded in his response, is the
details of PLDM (or any other protocol) starting to leak into other
processes.  We don't want people to notice that there is some piece of
information that isn't currently exposed via Inventory but happens to be
available in PLDM and start coding towards consuming it.  Hence, my
request that the design document the caveat I listed above.  We want to
limit the scope of applications that need to understand specific
protocols.

My suggestion would be to put these new proposed PLDM interfaces under
`Inventory/Source/PLDM`.  Anything under `Source` becomes one of these
"FRU-to-Inventory" transformational 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.

I don't like arbitrary string-based properties like this.  They aren't
documented and effectively become a private API between the processes.
In order for someone to make a new implementation they have to reverse
engineer the code.

> Thanks,
> Deepak

1. https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Inventory/Manager.interface.yaml

-- 
Patrick Williams

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

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

[Deepak Kodihalli]

On 28/05/20 5:33 pm, Patrick Williams wrote:
> On Tue, May 26, 2020 at 06:26:27PM +0530, Deepak Kodihalli wrote:
>> On 19/05/20 9:10 am, Deepak Kodihalli wrote:
>> 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.
> 
> After thinking about it for a bit, I think this is my preference with
> the design caveat that these are only consumed by processes which are
> "FRU-to-Inventory" transformers.  I would suggest putting these
> interfaces under the 'Inventory/' namespace somewhere to hopefully make
> this clearer.
> 
> We have two implementations of these "FRU-to-Inventory" transformers: EM
> and PIM.  Both of them have a form of dbus backdoor in order to get the
> information they need to create the Inventory objects they host.  PIM uses
> `Inventory/Manager`[1] and EM uses an undocumented `FruDevice` interface
> between it and 'fru-device'.  Both of these implementations do
> processing on the data they get (though, very minimal in the case of
> PIM) and create `Inventory/Item`s as a result.
> 
> What I am worried about, and Richard seconded in his response, is the
> details of PLDM (or any other protocol) starting to leak into other
> processes.  We don't want people to notice that there is some piece of
> information that isn't currently exposed via Inventory but happens to be
> available in PLDM and start coding towards consuming it.  Hence, my
> request that the design document the caveat I listed above.  We want to
> limit the scope of applications that need to understand specific
> protocols.
> 
> My suggestion would be to put these new proposed PLDM interfaces under
> `Inventory/Source/PLDM`.  Anything under `Source` becomes one of these
> "FRU-to-Inventory" transformational interfaces.


Makes sense to me. This makes the intent clearer. I've updated my commit 
on Gerrit. Please re-review.

Thanks,
Deepak

> 1. https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Inventory/Manager.interface.yaml

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

[Thomaiyar, Richard Marian]

On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
> On 28/05/20 5:33 pm, Patrick Williams wrote:
>> On Tue, May 26, 2020 at 06:26:27PM +0530, Deepak Kodihalli wrote:
>>> On 19/05/20 9:10 am, Deepak Kodihalli wrote:
>>> 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.
>>
>> After thinking about it for a bit, I think this is my preference with
>> the design caveat that these are only consumed by processes which are
>> "FRU-to-Inventory" transformers.  I would suggest putting these
>> interfaces under the 'Inventory/' namespace somewhere to hopefully make
>> this clearer.
>>
>> We have two implementations of these "FRU-to-Inventory" transformers: EM
>> and PIM.  Both of them have a form of dbus backdoor in order to get the
>> information they need to create the Inventory objects they host.  PIM 
>> uses
>> `Inventory/Manager`[1] and EM uses an undocumented `FruDevice` interface
>> between it and 'fru-device'.  Both of these implementations do
>> processing on the data they get (though, very minimal in the case of
>> PIM) and create `Inventory/Item`s as a result.
>>
>> What I am worried about, and Richard seconded in his response, is the
>> details of PLDM (or any other protocol) starting to leak into other
>> processes.  We don't want people to notice that there is some piece of
>> information that isn't currently exposed via Inventory but happens to be
>> available in PLDM and start coding towards consuming it.  Hence, my
>> request that the design document the caveat I listed above.  We want to
>> limit the scope of applications that need to understand specific
>> protocols.
>>
>> My suggestion would be to put these new proposed PLDM interfaces under
>> `Inventory/Source/PLDM`.  Anything under `Source` becomes one of these
>> "FRU-to-Inventory" transformational interfaces.
>
[Richard]:

Patrick / Deepak

Why do we need to have 2 different interfaces to represent the same 
information for FRU-to-inventory transformational (say ProductName). 
This will make inventory manager to be updated for every FRU producer?. 
Many of the properties are common, and we can form a common interface 
for that, and rest can be maintained in it's specific interface. I 
understand that current FRU to Entity-manager interface seems to be 
private, but we must make a common interface to represent like Product 
Name, PartNumer, Serial Number etc. (instead of maintaining it in 
different interface saying IPMI / PLDM Source, with different types). 
How about?

Inventory/Source/General/Fru  (Maintain common things here Product Name. 
This can be used by Inventory manager to advertise it (instead of 
searching it in multiple interfaces/properties))

Inventory/Source/PLDM   (Maintain PLDM specific stuff's here, say SKU, 
Engineering change level, IANA etc).

Inventory/Source/IPMI (Maintain IPMI FRU specific here)

Regards,

Richard

> Makes sense to me. This makes the intent clearer. I've updated my 
> commit on Gerrit. Please re-review.
>
> Thanks,
> Deepak
>
>> 1. 
>> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Inventory/Manager.interface.yaml
>

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

[Patrick Williams]

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

On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian wrote:
> 
> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
> > On 28/05/20 5:33 pm, Patrick Williams wrote:

> Why do we need to have 2 different interfaces to represent the same
> information for FRU-to-inventory transformational (say ProductName). This
> will make inventory manager to be updated for every FRU producer?. Many of
> the properties are common, and we can form a common interface for that, and
> rest can be maintained in it's specific interface. I understand that current
> FRU to Entity-manager interface seems to be private, but we must make a
> common interface to represent like Product Name, PartNumer, Serial Number
> etc. (instead of maintaining it in different interface saying IPMI / PLDM
> Source, with different types). How about?

Yes, I am in favor of common interfaces for this where ever possible.

Is there someone that knows the existing FruDevice implementation well
enough that can be included in this work to propose common interfaces
where it is appropriate?

> Inventory/Source/General/Fru  (Maintain common things here Product Name.
> This can be used by Inventory manager to advertise it (instead of searching
> it in multiple interfaces/properties))

Minor tweak here of 'Source/Common'?  When we have an existing Inventory
interface for this information should we mimic what is already in
Inventory?  At some point are we trying to be too common that we're
effectively reimplementing Inventory instances under a different name?

-- 
Patrick Williams

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

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

[James Feist]

On 5/28/2020 11:05 AM, Patrick Williams wrote:
> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian wrote:
>>
>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
> 
>> Why do we need to have 2 different interfaces to represent the same
>> information for FRU-to-inventory transformational (say ProductName). This
>> will make inventory manager to be updated for every FRU producer?. Many of
>> the properties are common, and we can form a common interface for that, and
>> rest can be maintained in it's specific interface. I understand that current
>> FRU to Entity-manager interface seems to be private, but we must make a
>> common interface to represent like Product Name, PartNumer, Serial Number
>> etc. (instead of maintaining it in different interface saying IPMI / PLDM
>> Source, with different types). How about?
> 
> Yes, I am in favor of common interfaces for this where ever possible.
> 
> Is there someone that knows the existing FruDevice implementation well
> enough that can be included in this work to propose common interfaces
> where it is appropriate?

Yes, I wrote it. I can review the changes, however if you read the ipmi 
fru spec, which is what fru device is based of, there are many optional 
fields based on the type of the fru. You'd probably at a minimum need an 
interface per region supported as phosphor-dbus-interfaces does not 
allow optional fields. I'm not sure how you'd deal with custom fields 
either. You'd probably need everything as a superset of the fru spec, 
and have blanks where its not populated.

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ipmi-platform-mgt-fru-info-storage-def-v1-0-rev-1-3-spec-update.pdf

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

[Deepak Kodihalli]

On 29/05/20 12:01 am, James Feist wrote:
> On 5/28/2020 11:05 AM, Patrick Williams wrote:
>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian 
>> wrote:
>>>
>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>
>>> Why do we need to have 2 different interfaces to represent the same
>>> information for FRU-to-inventory transformational (say ProductName). 
>>> This
>>> will make inventory manager to be updated for every FRU producer?. 
>>> Many of
>>> the properties are common, and we can form a common interface for 
>>> that, and
>>> rest can be maintained in it's specific interface. I understand that 
>>> current
>>> FRU to Entity-manager interface seems to be private, but we must make a
>>> common interface to represent like Product Name, PartNumer, Serial 
>>> Number
>>> etc. (instead of maintaining it in different interface saying IPMI / 
>>> PLDM
>>> Source, with different types). How about?
>>
>> Yes, I am in favor of common interfaces for this where ever possible.
>>
>> Is there someone that knows the existing FruDevice implementation well
>> enough that can be included in this work to propose common interfaces
>> where it is appropriate?
> 
> Yes, I wrote it. I can review the changes, however if you read the ipmi 
> fru spec, which is what fru device is based of, there are many optional 
> fields based on the type of the fru. You'd probably at a minimum need an 
> interface per region supported as phosphor-dbus-interfaces does not 
> allow optional fields. I'm not sure how you'd deal with custom fields 
> either. You'd probably need everything as a superset of the fru spec, 
> and have blanks where its not populated.


I don't think it is worth trying to make a FRU device/properties 
interface that is common to PLDM and IPMI. The two FRU formats are 
different (pls see my previous email about the same).

Thanks,
Deepak


> https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ipmi-platform-mgt-fru-info-storage-def-v1-0-rev-1-3-spec-update.pdf 
> 
> 
> 

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

[Deepak Kodihalli]

On 28/05/20 11:35 pm, Patrick Williams wrote:
> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian wrote:
>>
>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
> 
>> Why do we need to have 2 different interfaces to represent the same
>> information for FRU-to-inventory transformational (say ProductName). This
>> will make inventory manager to be updated for every FRU producer?. Many of
>> the properties are common, and we can form a common interface for that, and
>> rest can be maintained in it's specific interface. I understand that current
>> FRU to Entity-manager interface seems to be private, but we must make a
>> common interface to represent like Product Name, PartNumer, Serial Number
>> etc. (instead of maintaining it in different interface saying IPMI / PLDM
>> Source, with different types). How about?

Richard, I have concerns with this approach. Like I mentioned in one my 
earlier emails, and Patrick also alludes to below, if you try to make 
this common (event if it's for a subset of the properties) then you 
basically arrive at the existing phosphor Inventory interfaces (eg 
Inventory.Decorator.Asset).

My question in my earlier mail was, if you do such a thing, then why do 
you even need inventory producers? FruDevice and PLDM could have hosted 
inventory on their own. If they still rely on the inventory producers 
(EM and PIM) with this "common interface" approach, then it's basically 
re-implementation/duplications of the (Inventory.Decorator.Asset like) 
interface by two processes.

The idea is for apps like FruDevice and PLDM, which are aware of a 
specific FRU format, to host data in *that* format, to be consumed 
*solely* by inventory producers (like EM and PIM).

Also note that (as James pointed out in his email), the IPMI FRU format 
distinguishes Board/Chassis/Product areas. PLDM FRU format does not. So 
there are differences. If a new FRU format is introduced, then yes we 
would expect a new interface to show up under Inventory/Source/<FruFormat>


> Yes, I am in favor of common interfaces for this where ever possible.
> 
> Is there someone that knows the existing FruDevice implementation well
> enough that can be included in this work to propose common interfaces
> where it is appropriate?
> 
>> Inventory/Source/General/Fru  (Maintain common things here Product Name.
>> This can be used by Inventory manager to advertise it (instead of searching
>> it in multiple interfaces/properties))
> 
> Minor tweak here of 'Source/Common'?  When we have an existing Inventory
> interface for this information should we mimic what is already in
> Inventory?  At some point are we trying to be too common that we're
> effectively reimplementing Inventory instances under a different name?
> 

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

[Thomaiyar, Richard Marian]

On 5/29/2020 10:39 AM, Deepak Kodihalli wrote:
> On 28/05/20 11:35 pm, Patrick Williams wrote:
>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian 
>> wrote:
>>>
>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>
>>> Why do we need to have 2 different interfaces to represent the same
>>> information for FRU-to-inventory transformational (say ProductName). 
>>> This
>>> will make inventory manager to be updated for every FRU producer?. 
>>> Many of
>>> the properties are common, and we can form a common interface for 
>>> that, and
>>> rest can be maintained in it's specific interface. I understand that 
>>> current
>>> FRU to Entity-manager interface seems to be private, but we must make a
>>> common interface to represent like Product Name, PartNumer, Serial 
>>> Number
>>> etc. (instead of maintaining it in different interface saying IPMI / 
>>> PLDM
>>> Source, with different types). How about?
>
> Richard, I have concerns with this approach. Like I mentioned in one 
> my earlier emails, and Patrick also alludes to below, if you try to 
> make this common (event if it's for a subset of the properties) then 
> you basically arrive at the existing phosphor Inventory interfaces (eg 
> Inventory.Decorator.Asset).
>
> My question in my earlier mail was, if you do such a thing, then why 
> do you even need inventory producers? FruDevice and PLDM could have 
> hosted inventory on their own. If they still rely on the inventory 
> producers (EM and PIM) with this "common interface" approach, then 
> it's basically re-implementation/duplications of the 
> (Inventory.Decorator.Asset like) interface by two processes.

[Richard]: Basically FRU information (either IPMI/PLDM) is needed for 
the inventory producers to expose configuration, which FRU will not 
have. Say, based on FRU Product name, either we will expose 4 temp 
sensor / 2 (Now along with this one, we need to inform the product name 
through Inventory.Decorator.Asset). Now from Redfish point of it, 
Inventory.Decorator is what it uses. This is what i was asking with 2 
options in earlier mail (whether to change or stick with it (recommended)).

>
> The idea is for apps like FruDevice and PLDM, which are aware of a 
> specific FRU format, to host data in *that* format, to be consumed 
> *solely* by inventory producers (like EM and PIM).
>
[Richard]: Yes, but it doesn't need to expose those in that format? Say 
Manufacturer Name, it doesn't mater whether it is coming from PLDM FRU / 
IPMI FRU. Say we have a special handling for a particular manufacture / 
product, then irrespective of inventory producers both can handle the same.

If we have 2 different interface, then inventory producer may need to be 
aware about both and probe it accordingly. FRU producers code must be 
written in such a way that for these common properties it does the 
necessary conversion (Say make manufacturer as string, irrespective of 
any format it read through). Note: Specific stuff, we need to create a 
separate interface (as phosphor-dbus-interface at present doesn't 
support dynamic property addition/deletion). (Tomorrow, if we have any 
other proprietary way of producing FRU data, we can still work with this 
approach, with less or no change for other layers).

> Also note that (as James pointed out in his email), the IPMI FRU 
> format distinguishes Board/Chassis/Product areas. PLDM FRU format does 
> not. So there are differences. If a new FRU format is introduced, then 
> yes we would expect a new interface to show up under 
> Inventory/Source/<FruFormat>
[Richard]: Fru producers should do this conversion. Say Chassis Type 
(Irrespective of what area it comes from it is same). PLDM FRU mostly 
represents the product as a whole, but technically we can point it to 
all the needed using the Fru Record set to the Entity type mapping in 
the PDR record. Accordingly it needs to be exposed.
>
>
>> Yes, I am in favor of common interfaces for this where ever possible.
>>
>> Is there someone that knows the existing FruDevice implementation well
>> enough that can be included in this work to propose common interfaces
>> where it is appropriate?
>>
>>> Inventory/Source/General/Fru  (Maintain common things here Product 
>>> Name.
>>> This can be used by Inventory manager to advertise it (instead of 
>>> searching
>>> it in multiple interfaces/properties))
>>
>> Minor tweak here of 'Source/Common'?  When we have an existing Inventory
>> interface for this information should we mimic what is already in
>> Inventory?  At some point are we trying to be too common that we're
>> effectively reimplementing Inventory instances under a different name?
>>
[Richard]: Yes, currently, FRU to inventory and inventory to upper layer 
is what used. If we want to change it, we need to go with differnt 
option of using FRU to upper layer, but many of existing code will 
require change.

Regards,

Richard

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

[Deepak Kodihalli]

On 29/05/20 12:47 pm, Thomaiyar, Richard Marian wrote:
> 
> On 5/29/2020 10:39 AM, Deepak Kodihalli wrote:
>> On 28/05/20 11:35 pm, Patrick Williams wrote:
>>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian 
>>> wrote:
>>>>
>>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>>
>>>> Why do we need to have 2 different interfaces to represent the same
>>>> information for FRU-to-inventory transformational (say ProductName). 
>>>> This
>>>> will make inventory manager to be updated for every FRU producer?. 
>>>> Many of
>>>> the properties are common, and we can form a common interface for 
>>>> that, and
>>>> rest can be maintained in it's specific interface. I understand that 
>>>> current
>>>> FRU to Entity-manager interface seems to be private, but we must make a
>>>> common interface to represent like Product Name, PartNumer, Serial 
>>>> Number
>>>> etc. (instead of maintaining it in different interface saying IPMI / 
>>>> PLDM
>>>> Source, with different types). How about?
>>
>> Richard, I have concerns with this approach. Like I mentioned in one 
>> my earlier emails, and Patrick also alludes to below, if you try to 
>> make this common (event if it's for a subset of the properties) then 
>> you basically arrive at the existing phosphor Inventory interfaces (eg 
>> Inventory.Decorator.Asset).
>>
>> My question in my earlier mail was, if you do such a thing, then why 
>> do you even need inventory producers? FruDevice and PLDM could have 
>> hosted inventory on their own. If they still rely on the inventory 
>> producers (EM and PIM) with this "common interface" approach, then 
>> it's basically re-implementation/duplications of the 
>> (Inventory.Decorator.Asset like) interface by two processes.

Richard, what is your thought on the re-implementation/duplication 
concern above? I'm not sure if you answered that and I missed.

> [Richard]: Basically FRU information (either IPMI/PLDM) is needed for 
> the inventory producers to expose configuration, which FRU will not 
> have. Say, based on FRU Product name, either we will expose 4 temp 
> sensor / 2 (Now along with this one, we need to inform the product name 
> through Inventory.Decorator.Asset). Now from Redfish point of it, 
> Inventory.Decorator is what it uses. This is what i was asking with 2 
> options in earlier mail (whether to change or stick with it (recommended)).

>>
>> The idea is for apps like FruDevice and PLDM, which are aware of a 
>> specific FRU format, to host data in *that* format, to be consumed 
>> *solely* by inventory producers (like EM and PIM).
>>
> [Richard]: Yes, but it doesn't need to expose those in that format?

Why not?

> Say Manufacturer Name, it doesn't mater whether it is coming from PLDM FRU / 
> IPMI FRU. Say we have a special handling for a particular manufacture / 
> product, then irrespective of inventory producers both can handle the same.

This is what the Inventory.Decorator.Asset interface is for.

> If we have 2 different interface, then inventory producer may need to be 
> aware about both and probe it accordingly.

No, the "FRU" properties producer needs to be concerned only about the 
format it understands.

> FRU producers code must be 
> written in such a way that for these common properties it does the 
> necessary conversion (Say make manufacturer as string, irrespective of 
> any format it read through). Note: Specific stuff, we need to create a 
> separate interface (as phosphor-dbus-interface at present doesn't 
> support dynamic property addition/deletion). (Tomorrow, if we have any 
> other proprietary way of producing FRU data, we can still work with this 
> approach, with less or no change for other layers).
> 
>> Also note that (as James pointed out in his email), the IPMI FRU 
>> format distinguishes Board/Chassis/Product areas. PLDM FRU format does 
>> not. So there are differences. If a new FRU format is introduced, then 
>> yes we would expect a new interface to show up under 
>> Inventory/Source/<FruFormat>
> [Richard]: Fru producers should do this conversion.

I'm of the opinion that the inventory producer (like EM and PIM) should 
perform this conversion. Consider 
https://github.com/openbmc/entity-manager/blob/master/configurations/Intel%20Front%20Panel.json#L55 
for example. I don't think it's up to the FruDevice/PLDM kind of apps to 
decide that this is actually a Panel. You can design it that way, but 
like I said above that means the config knowledge moves into these apps, 
which I don't think we should head towards, since then every FRU 
producer app needs to do this. This is why we have apps like EM.

> Say Chassis Type 
> (Irrespective of what area it comes from it is same). PLDM FRU mostly 
> represents the product as a whole, but technically we can point it to 
> all the needed using the Fru Record set to the Entity type mapping in 
> the PDR record. Accordingly it needs to be exposed.
>>
>>
>>> Yes, I am in favor of common interfaces for this where ever possible.
>>>
>>> Is there someone that knows the existing FruDevice implementation well
>>> enough that can be included in this work to propose common interfaces
>>> where it is appropriate?
>>>
>>>> Inventory/Source/General/Fru  (Maintain common things here Product 
>>>> Name.
>>>> This can be used by Inventory manager to advertise it (instead of 
>>>> searching
>>>> it in multiple interfaces/properties))
>>>
>>> Minor tweak here of 'Source/Common'?  When we have an existing Inventory
>>> interface for this information should we mimic what is already in
>>> Inventory?  At some point are we trying to be too common that we're
>>> effectively reimplementing Inventory instances under a different name?
>>>
> [Richard]: Yes, currently, FRU to inventory and inventory to upper layer 
> is what used. If we want to change it, we need to go with differnt 
> option of using FRU to upper layer, but many of existing code will 
> require change.


> Regards,
> 
> Richard
> 

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

[Thomaiyar, Richard Marian]

On 5/29/2020 1:01 PM, Deepak Kodihalli wrote:
> On 29/05/20 12:47 pm, Thomaiyar, Richard Marian wrote:
>>
>> On 5/29/2020 10:39 AM, Deepak Kodihalli wrote:
>>> On 28/05/20 11:35 pm, Patrick Williams wrote:
>>>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian 
>>>> wrote:
>>>>>
>>>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>>>
>>>>> Why do we need to have 2 different interfaces to represent the same
>>>>> information for FRU-to-inventory transformational (say 
>>>>> ProductName). This
>>>>> will make inventory manager to be updated for every FRU producer?. 
>>>>> Many of
>>>>> the properties are common, and we can form a common interface for 
>>>>> that, and
>>>>> rest can be maintained in it's specific interface. I understand 
>>>>> that current
>>>>> FRU to Entity-manager interface seems to be private, but we must 
>>>>> make a
>>>>> common interface to represent like Product Name, PartNumer, Serial 
>>>>> Number
>>>>> etc. (instead of maintaining it in different interface saying IPMI 
>>>>> / PLDM
>>>>> Source, with different types). How about?
>>>
>>> Richard, I have concerns with this approach. Like I mentioned in one 
>>> my earlier emails, and Patrick also alludes to below, if you try to 
>>> make this common (event if it's for a subset of the properties) then 
>>> you basically arrive at the existing phosphor Inventory interfaces 
>>> (eg Inventory.Decorator.Asset).
>>>
>>> My question in my earlier mail was, if you do such a thing, then why 
>>> do you even need inventory producers? FruDevice and PLDM could have 
>>> hosted inventory on their own. If they still rely on the inventory 
>>> producers (EM and PIM) with this "common interface" approach, then 
>>> it's basically re-implementation/duplications of the 
>>> (Inventory.Decorator.Asset like) interface by two processes.
>
> Richard, what is your thought on the re-implementation/duplication 
> concern above? I'm not sure if you answered that and I missed.
[Richard]: FRU Consumers must be aware about each and every Format 
specifically, even though it conveys same meaning.
>
>> [Richard]: Basically FRU information (either IPMI/PLDM) is needed for 
>> the inventory producers to expose configuration, which FRU will not 
>> have. Say, based on FRU Product name, either we will expose 4 temp 
>> sensor / 2 (Now along with this one, we need to inform the product 
>> name through Inventory.Decorator.Asset). Now from Redfish point of 
>> it, Inventory.Decorator is what it uses. This is what i was asking 
>> with 2 options in earlier mail (whether to change or stick with it 
>> (recommended)).
>
>>>
>>> The idea is for apps like FruDevice and PLDM, which are aware of a 
>>> specific FRU format, to host data in *that* format, to be consumed 
>>> *solely* by inventory producers (like EM and PIM).
>>>
>> [Richard]: Yes, but it doesn't need to expose those in that format?
>
> Why not?
[Richard]: What's the advantage in keeping it in that format itself? 
This is used only by EM / PIM, and not by redfish directly right? Where 
the intelligence must reside in the producer or consumer (With producer, 
consumers can be in common form)
>
>> Say Manufacturer Name, it doesn't mater whether it is coming from 
>> PLDM FRU / IPMI FRU. Say we have a special handling for a particular 
>> manufacture / product, then irrespective of inventory producers both 
>> can handle the same.
>
> This is what the Inventory.Decorator.Asset interface is for.
[Richard]: Yes, That is exposed by EM / PIM in our case. Why EM / PIM 
must rely on 2 different stuff, for common things is the question here.
>
>> If we have 2 different interface, then inventory producer may need to 
>> be aware about both and probe it accordingly.
>
> No, the "FRU" properties producer needs to be concerned only about the 
> format it understands.

[Richard]: FRU property producer must know the format and produce the 
interface with data (in common form as much as possible). E.g. IPMI FRU 
Producer (say xyz.openbmc_project.FruDevice service) will read device A 
FRU, and expose the Manufacturer name (It can read the EEPROM content 
and decode it as per the IPMI FRU format, but the data it produces is 
Manufacturer name). Simiarly PLDM FRU Producer (say 
xyz.openbmc_project.PLDM.FruDevice service) will read the data using 
PLDM FRU commands, and expose the Manufacturer name. Now why this 2 
service need to have 2 different interface(one from 
Inventory.Source.PLDM & another from Inventory.Source.IPMI, to expose 
the Manufacturer name. ? Why Entity manager / PIM need to read the same 
information from 2 different interface and expose it in 
Inventory.Decorator.Asset. (It can do it with same interface). What 
Entity manager / PIM needs to do is using Object Mapper query all the 
FruDevices (IPMI / PLDM FRU), and accordingly expose the Inventory.

>> FRU producers code must be written in such a way that for these 
>> common properties it does the necessary conversion (Say make 
>> manufacturer as string, irrespective of any format it read through). 
>> Note: Specific stuff, we need to create a separate interface (as 
>> phosphor-dbus-interface at present doesn't support dynamic property 
>> addition/deletion). (Tomorrow, if we have any other proprietary way 
>> of producing FRU data, we can still work with this approach, with 
>> less or no change for other layers).
>>
>>> Also note that (as James pointed out in his email), the IPMI FRU 
>>> format distinguishes Board/Chassis/Product areas. PLDM FRU format 
>>> does not. So there are differences. If a new FRU format is 
>>> introduced, then yes we would expect a new interface to show up 
>>> under Inventory/Source/<FruFormat>
>> [Richard]: Fru producers should do this conversion.
>
> I'm of the opinion that the inventory producer (like EM and PIM) 
> should perform this conversion. Consider 
> https://github.com/openbmc/entity-manager/blob/master/configurations/Intel%20Front%20Panel.json#L55 
> for example. I don't think it's up to the FruDevice/PLDM kind of apps 
> to decide that this is actually a Panel. You can design it that way, 
> but like I said above that means the config knowledge moves into these 
> apps, which I don't think we should head towards, since then every FRU 
> producer app needs to do this. This is why we have apps like EM.
[Richard]: Exactly. What we need to make sure is create abstraction 
between Entity manager and FRU Producers as much as possible. FRU 
Producer responsibility is to read the FRU in decode the FRU data as per 
the spec and expose it in common form which Entity-manager / PIM will 
rely on.
>
>> Say Chassis Type (Irrespective of what area it comes from it is 
>> same). PLDM FRU mostly represents the product as a whole, but 
>> technically we can point it to all the needed using the Fru Record 
>> set to the Entity type mapping in the PDR record. Accordingly it 
>> needs to be exposed.
>>>
>>>
>>>> Yes, I am in favor of common interfaces for this where ever possible.
>>>>
>>>> Is there someone that knows the existing FruDevice implementation well
>>>> enough that can be included in this work to propose common interfaces
>>>> where it is appropriate?
>>>>
>>>>> Inventory/Source/General/Fru (Maintain common things here Product 
>>>>> Name.
>>>>> This can be used by Inventory manager to advertise it (instead of 
>>>>> searching
>>>>> it in multiple interfaces/properties))
>>>>
>>>> Minor tweak here of 'Source/Common'?  When we have an existing 
>>>> Inventory
>>>> interface for this information should we mimic what is already in
>>>> Inventory?  At some point are we trying to be too common that we're
>>>> effectively reimplementing Inventory instances under a different name?
>>>>
>> [Richard]: Yes, currently, FRU to inventory and inventory to upper 
>> layer is what used. If we want to change it, we need to go with 
>> differnt option of using FRU to upper layer, but many of existing 
>> code will require change.
>
>
>> Regards,
>>
>> Richard
>>
>

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

[Deepak Kodihalli]

On 29/05/20 2:33 pm, Thomaiyar, Richard Marian wrote:
> 
> On 5/29/2020 1:01 PM, Deepak Kodihalli wrote:
>> On 29/05/20 12:47 pm, Thomaiyar, Richard Marian wrote:
>>>
>>> On 5/29/2020 10:39 AM, Deepak Kodihalli wrote:
>>>> On 28/05/20 11:35 pm, Patrick Williams wrote:
>>>>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard Marian 
>>>>> wrote:
>>>>>>
>>>>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>>>>
>>>>>> Why do we need to have 2 different interfaces to represent the same
>>>>>> information for FRU-to-inventory transformational (say 
>>>>>> ProductName). This
>>>>>> will make inventory manager to be updated for every FRU producer?. 
>>>>>> Many of
>>>>>> the properties are common, and we can form a common interface for 
>>>>>> that, and
>>>>>> rest can be maintained in it's specific interface. I understand 
>>>>>> that current
>>>>>> FRU to Entity-manager interface seems to be private, but we must 
>>>>>> make a
>>>>>> common interface to represent like Product Name, PartNumer, Serial 
>>>>>> Number
>>>>>> etc. (instead of maintaining it in different interface saying IPMI 
>>>>>> / PLDM
>>>>>> Source, with different types). How about?
>>>>
>>>> Richard, I have concerns with this approach. Like I mentioned in one 
>>>> my earlier emails, and Patrick also alludes to below, if you try to 
>>>> make this common (event if it's for a subset of the properties) then 
>>>> you basically arrive at the existing phosphor Inventory interfaces 
>>>> (eg Inventory.Decorator.Asset).
>>>>
>>>> My question in my earlier mail was, if you do such a thing, then why 
>>>> do you even need inventory producers? FruDevice and PLDM could have 
>>>> hosted inventory on their own. If they still rely on the inventory 
>>>> producers (EM and PIM) with this "common interface" approach, then 
>>>> it's basically re-implementation/duplications of the 
>>>> (Inventory.Decorator.Asset like) interface by two processes.
>>
>> Richard, what is your thought on the re-implementation/duplication 
>> concern above? I'm not sure if you answered that and I missed.
> [Richard]: FRU Consumers must be aware about each and every Format 
> specifically, even though it conveys same meaning.

I agree with that, but my question was about FRU producers.


>>> [Richard]: Basically FRU information (either IPMI/PLDM) is needed for 
>>> the inventory producers to expose configuration, which FRU will not 
>>> have. Say, based on FRU Product name, either we will expose 4 temp 
>>> sensor / 2 (Now along with this one, we need to inform the product 
>>> name through Inventory.Decorator.Asset). Now from Redfish point of 
>>> it, Inventory.Decorator is what it uses. This is what i was asking 
>>> with 2 options in earlier mail (whether to change or stick with it 
>>> (recommended)).
>>
>>>>
>>>> The idea is for apps like FruDevice and PLDM, which are aware of a 
>>>> specific FRU format, to host data in *that* format, to be consumed 
>>>> *solely* by inventory producers (like EM and PIM).
>>>>
>>> [Richard]: Yes, but it doesn't need to expose those in that format?
>>
>> Why not?
> [Richard]: What's the advantage in keeping it in that format itself?

The advantage I see is basically what you said on the next line.

> This is used only by EM / PIM, and not by redfish directly right? Where 
> the intelligence must reside in the producer or consumer (With producer, 
> consumers can be in common form)

>>> Say Manufacturer Name, it doesn't mater whether it is coming from 
>>> PLDM FRU / IPMI FRU. Say we have a special handling for a particular 
>>> manufacture / product, then irrespective of inventory producers both 
>>> can handle the same.
>>
>> This is what the Inventory.Decorator.Asset interface is for.
> [Richard]: Yes, That is exposed by EM / PIM in our case. Why EM / PIM 
> must rely on 2 different stuff, for common things is the question here.
>>
>>> If we have 2 different interface, then inventory producer may need to 
>>> be aware about both and probe it accordingly.
>>
>> No, the "FRU" properties producer needs to be concerned only about the 
>> format it understands.
> 
> [Richard]: FRU property producer must know the format and produce the 
> interface with data (in common form as much as possible). E.g. IPMI FRU 
> Producer (say xyz.openbmc_project.FruDevice service) will read device A 
> FRU, and expose the Manufacturer name (It can read the EEPROM content 
> and decode it as per the IPMI FRU format, but the data it produces is 
> Manufacturer name). Simiarly PLDM FRU Producer (say 
> xyz.openbmc_project.PLDM.FruDevice service) will read the data using 
> PLDM FRU commands, and expose the Manufacturer name. Now why this 2 
> service need to have 2 different interface(one from 
> Inventory.Source.PLDM & another from Inventory.Source.IPMI, to expose 
> the Manufacturer name. ? Why Entity manager / PIM need to read the same 
> information from 2 different interface and expose it in 
> Inventory.Decorator.Asset. (It can do it with same interface).

What is that interface?

> What Entity manager / PIM needs to do is using Object Mapper query all the 
> FruDevices (IPMI / PLDM FRU), and accordingly expose the Inventory
>>> FRU producers code must be written in such a way that for these 
>>> common properties it does the necessary conversion (Say make 
>>> manufacturer as string, irrespective of any format it read through). 
>>> Note: Specific stuff, we need to create a separate interface (as 
>>> phosphor-dbus-interface at present doesn't support dynamic property 
>>> addition/deletion). (Tomorrow, if we have any other proprietary way 
>>> of producing FRU data, we can still work with this approach, with 
>>> less or no change for other layers).
>>>
>>>> Also note that (as James pointed out in his email), the IPMI FRU 
>>>> format distinguishes Board/Chassis/Product areas. PLDM FRU format 
>>>> does not. So there are differences. If a new FRU format is 
>>>> introduced, then yes we would expect a new interface to show up 
>>>> under Inventory/Source/<FruFormat>
>>> [Richard]: Fru producers should do this conversion.
>>
>> I'm of the opinion that the inventory producer (like EM and PIM) 
>> should perform this conversion. Consider 
>> https://github.com/openbmc/entity-manager/blob/master/configurations/Intel%20Front%20Panel.json#L55 
>> for example. I don't think it's up to the FruDevice/PLDM kind of apps 
>> to decide that this is actually a Panel. You can design it that way, 
>> but like I said above that means the config knowledge moves into these 
>> apps, which I don't think we should head towards, since then every FRU 
>> producer app needs to do this. This is why we have apps like EM.
> [Richard]: Exactly. What we need to make sure is create abstraction 
> between Entity manager and FRU Producers as much as possible. FRU 
> Producer responsibility is to read the FRU in decode the FRU data as per 
> the spec and expose it in common form which Entity-manager / PIM will 
> rely on.

I don't see why the abstraction is necessary. There already is 
abstraction in terms of the phosphor interfaces.

>>> Say Chassis Type (Irrespective of what area it comes from it is 
>>> same). PLDM FRU mostly represents the product as a whole, but 
>>> technically we can point it to all the needed using the Fru Record 
>>> set to the Entity type mapping in the PDR record. Accordingly it 
>>> needs to be exposed.
>>>>
>>>>
>>>>> Yes, I am in favor of common interfaces for this where ever possible.
>>>>>
>>>>> Is there someone that knows the existing FruDevice implementation well
>>>>> enough that can be included in this work to propose common interfaces
>>>>> where it is appropriate?
>>>>>
>>>>>> Inventory/Source/General/Fru (Maintain common things here Product 
>>>>>> Name.
>>>>>> This can be used by Inventory manager to advertise it (instead of 
>>>>>> searching
>>>>>> it in multiple interfaces/properties))
>>>>>
>>>>> Minor tweak here of 'Source/Common'?  When we have an existing 
>>>>> Inventory
>>>>> interface for this information should we mimic what is already in
>>>>> Inventory?  At some point are we trying to be too common that we're
>>>>> effectively reimplementing Inventory instances under a different name?
>>>>>
>>> [Richard]: Yes, currently, FRU to inventory and inventory to upper 
>>> layer is what used. If we want to change it, we need to go with 
>>> differnt option of using FRU to upper layer, but many of existing 
>>> code will require change.
>>
>>
>>> Regards,
>>>
>>> Richard
>>>
>>

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

[Deepak Kodihalli]

On 29/05/20 3:49 pm, Deepak Kodihalli wrote:
> On 29/05/20 2:33 pm, Thomaiyar, Richard Marian wrote:
>>
>> On 5/29/2020 1:01 PM, Deepak Kodihalli wrote:
>>> On 29/05/20 12:47 pm, Thomaiyar, Richard Marian wrote:
>>>>
>>>> On 5/29/2020 10:39 AM, Deepak Kodihalli wrote:
>>>>> On 28/05/20 11:35 pm, Patrick Williams wrote:
>>>>>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard 
>>>>>> Marian wrote:
>>>>>>>
>>>>>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>>>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>>>>>
>>>>>>> Why do we need to have 2 different interfaces to represent the same
>>>>>>> information for FRU-to-inventory transformational (say 
>>>>>>> ProductName). This
>>>>>>> will make inventory manager to be updated for every FRU 
>>>>>>> producer?. Many of
>>>>>>> the properties are common, and we can form a common interface for 
>>>>>>> that, and
>>>>>>> rest can be maintained in it's specific interface. I understand 
>>>>>>> that current
>>>>>>> FRU to Entity-manager interface seems to be private, but we must 
>>>>>>> make a
>>>>>>> common interface to represent like Product Name, PartNumer, 
>>>>>>> Serial Number
>>>>>>> etc. (instead of maintaining it in different interface saying 
>>>>>>> IPMI / PLDM
>>>>>>> Source, with different types). How about?
>>>>>
>>>>> Richard, I have concerns with this approach. Like I mentioned in 
>>>>> one my earlier emails, and Patrick also alludes to below, if you 
>>>>> try to make this common (event if it's for a subset of the 
>>>>> properties) then you basically arrive at the existing phosphor 
>>>>> Inventory interfaces (eg Inventory.Decorator.Asset).
>>>>>
>>>>> My question in my earlier mail was, if you do such a thing, then 
>>>>> why do you even need inventory producers? FruDevice and PLDM could 
>>>>> have hosted inventory on their own. If they still rely on the 
>>>>> inventory producers (EM and PIM) with this "common interface" 
>>>>> approach, then it's basically re-implementation/duplications of the 
>>>>> (Inventory.Decorator.Asset like) interface by two processes.
>>>
>>> Richard, what is your thought on the re-implementation/duplication 
>>> concern above? I'm not sure if you answered that and I missed.
>> [Richard]: FRU Consumers must be aware about each and every Format 
>> specifically, even though it conveys same meaning.
> 
> I agree with that, but my question was about FRU producers.
> 
> 
>>>> [Richard]: Basically FRU information (either IPMI/PLDM) is needed 
>>>> for the inventory producers to expose configuration, which FRU will 
>>>> not have. Say, based on FRU Product name, either we will expose 4 
>>>> temp sensor / 2 (Now along with this one, we need to inform the 
>>>> product name through Inventory.Decorator.Asset). Now from Redfish 
>>>> point of it, Inventory.Decorator is what it uses. This is what i was 
>>>> asking with 2 options in earlier mail (whether to change or stick 
>>>> with it (recommended)).
>>>
>>>>>
>>>>> The idea is for apps like FruDevice and PLDM, which are aware of a 
>>>>> specific FRU format, to host data in *that* format, to be consumed 
>>>>> *solely* by inventory producers (like EM and PIM).
>>>>>
>>>> [Richard]: Yes, but it doesn't need to expose those in that format?
>>>
>>> Why not?
>> [Richard]: What's the advantage in keeping it in that format itself?
> 
> The advantage I see is basically what you said on the next line.
> 
>> This is used only by EM / PIM, and not by redfish directly right? 
>> Where the intelligence must reside in the producer or consumer (With 
>> producer, consumers can be in common form)
> 
>>>> Say Manufacturer Name, it doesn't mater whether it is coming from 
>>>> PLDM FRU / IPMI FRU. Say we have a special handling for a particular 
>>>> manufacture / product, then irrespective of inventory producers both 
>>>> can handle the same.
>>>
>>> This is what the Inventory.Decorator.Asset interface is for.
>> [Richard]: Yes, That is exposed by EM / PIM in our case. Why EM / PIM 
>> must rely on 2 different stuff, for common things is the question here.
>>>
>>>> If we have 2 different interface, then inventory producer may need 
>>>> to be aware about both and probe it accordingly.
>>>
>>> No, the "FRU" properties producer needs to be concerned only about 
>>> the format it understands.
>>
>> [Richard]: FRU property producer must know the format and produce the 
>> interface with data (in common form as much as possible). E.g. IPMI 
>> FRU Producer (say xyz.openbmc_project.FruDevice service) will read 
>> device A FRU, and expose the Manufacturer name (It can read the EEPROM 
>> content and decode it as per the IPMI FRU format, but the data it 
>> produces is Manufacturer name). Simiarly PLDM FRU Producer (say 
>> xyz.openbmc_project.PLDM.FruDevice service) will read the data using 
>> PLDM FRU commands, and expose the Manufacturer name. Now why this 2 
>> service need to have 2 different interface(one from 
>> Inventory.Source.PLDM & another from Inventory.Source.IPMI, to expose 
>> the Manufacturer name. ? Why Entity manager / PIM need to read the 
>> same information from 2 different interface and expose it in 
>> Inventory.Decorator.Asset. (It can do it with same interface).
> 
> What is that interface?


@Richard - to elaborate further - on Gerrit you suggest moving things 
like Serial Number and Part Number to Inventory.Decorator.Asset. 
However, note that these are already present in 
Inventory.Decorator.Asset. Hence the question - why do want FruDevice, 
PLDM, EM, PIM to all implement Inventory.Decorator.Asset?


>> What Entity manager / PIM needs to do is using Object Mapper query all 
>> the FruDevices (IPMI / PLDM FRU), and accordingly expose the Inventory
>>>> FRU producers code must be written in such a way that for these 
>>>> common properties it does the necessary conversion (Say make 
>>>> manufacturer as string, irrespective of any format it read through). 
>>>> Note: Specific stuff, we need to create a separate interface (as 
>>>> phosphor-dbus-interface at present doesn't support dynamic property 
>>>> addition/deletion). (Tomorrow, if we have any other proprietary way 
>>>> of producing FRU data, we can still work with this approach, with 
>>>> less or no change for other layers).
>>>>
>>>>> Also note that (as James pointed out in his email), the IPMI FRU 
>>>>> format distinguishes Board/Chassis/Product areas. PLDM FRU format 
>>>>> does not. So there are differences. If a new FRU format is 
>>>>> introduced, then yes we would expect a new interface to show up 
>>>>> under Inventory/Source/<FruFormat>
>>>> [Richard]: Fru producers should do this conversion.
>>>
>>> I'm of the opinion that the inventory producer (like EM and PIM) 
>>> should perform this conversion. Consider 
>>> https://github.com/openbmc/entity-manager/blob/master/configurations/Intel%20Front%20Panel.json#L55 
>>> for example. I don't think it's up to the FruDevice/PLDM kind of apps 
>>> to decide that this is actually a Panel. You can design it that way, 
>>> but like I said above that means the config knowledge moves into 
>>> these apps, which I don't think we should head towards, since then 
>>> every FRU producer app needs to do this. This is why we have apps 
>>> like EM.
>> [Richard]: Exactly. What we need to make sure is create abstraction 
>> between Entity manager and FRU Producers as much as possible. FRU 
>> Producer responsibility is to read the FRU in decode the FRU data as 
>> per the spec and expose it in common form which Entity-manager / PIM 
>> will rely on.
> 
> I don't see why the abstraction is necessary. There already is 
> abstraction in terms of the phosphor interfaces.
> 
>>>> Say Chassis Type (Irrespective of what area it comes from it is 
>>>> same). PLDM FRU mostly represents the product as a whole, but 
>>>> technically we can point it to all the needed using the Fru Record 
>>>> set to the Entity type mapping in the PDR record. Accordingly it 
>>>> needs to be exposed.
>>>>>
>>>>>
>>>>>> Yes, I am in favor of common interfaces for this where ever possible.
>>>>>>
>>>>>> Is there someone that knows the existing FruDevice implementation 
>>>>>> well
>>>>>> enough that can be included in this work to propose common interfaces
>>>>>> where it is appropriate?
>>>>>>
>>>>>>> Inventory/Source/General/Fru (Maintain common things here Product 
>>>>>>> Name.
>>>>>>> This can be used by Inventory manager to advertise it (instead of 
>>>>>>> searching
>>>>>>> it in multiple interfaces/properties))
>>>>>>
>>>>>> Minor tweak here of 'Source/Common'?  When we have an existing 
>>>>>> Inventory
>>>>>> interface for this information should we mimic what is already in
>>>>>> Inventory?  At some point are we trying to be too common that we're
>>>>>> effectively reimplementing Inventory instances under a different 
>>>>>> name?
>>>>>>
>>>> [Richard]: Yes, currently, FRU to inventory and inventory to upper 
>>>> layer is what used. If we want to change it, we need to go with 
>>>> differnt option of using FRU to upper layer, but many of existing 
>>>> code will require change.
>>>
>>>
>>>> Regards,
>>>>
>>>> Richard
>>>>
>>>
> 

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

[Thomaiyar, Richard Marian]

On 5/29/2020 4:00 PM, Deepak Kodihalli wrote:
> On 29/05/20 3:49 pm, Deepak Kodihalli wrote:
>> On 29/05/20 2:33 pm, Thomaiyar, Richard Marian wrote:
>>>
>>> On 5/29/2020 1:01 PM, Deepak Kodihalli wrote:
>>>> On 29/05/20 12:47 pm, Thomaiyar, Richard Marian wrote:
>>>>>
>>>>> On 5/29/2020 10:39 AM, Deepak Kodihalli wrote:
>>>>>> On 28/05/20 11:35 pm, Patrick Williams wrote:
>>>>>>> On Thu, May 28, 2020 at 10:12:19PM +0530, Thomaiyar, Richard 
>>>>>>> Marian wrote:
>>>>>>>>
>>>>>>>> On 5/28/2020 5:54 PM, Deepak Kodihalli wrote:
>>>>>>>>> On 28/05/20 5:33 pm, Patrick Williams wrote:
>>>>>>>
>>>>>>>> Why do we need to have 2 different interfaces to represent the 
>>>>>>>> same
>>>>>>>> information for FRU-to-inventory transformational (say 
>>>>>>>> ProductName). This
>>>>>>>> will make inventory manager to be updated for every FRU 
>>>>>>>> producer?. Many of
>>>>>>>> the properties are common, and we can form a common interface 
>>>>>>>> for that, and
>>>>>>>> rest can be maintained in it's specific interface. I understand 
>>>>>>>> that current
>>>>>>>> FRU to Entity-manager interface seems to be private, but we 
>>>>>>>> must make a
>>>>>>>> common interface to represent like Product Name, PartNumer, 
>>>>>>>> Serial Number
>>>>>>>> etc. (instead of maintaining it in different interface saying 
>>>>>>>> IPMI / PLDM
>>>>>>>> Source, with different types). How about?
>>>>>>
>>>>>> Richard, I have concerns with this approach. Like I mentioned in 
>>>>>> one my earlier emails, and Patrick also alludes to below, if you 
>>>>>> try to make this common (event if it's for a subset of the 
>>>>>> properties) then you basically arrive at the existing phosphor 
>>>>>> Inventory interfaces (eg Inventory.Decorator.Asset).
>>>>>>
>>>>>> My question in my earlier mail was, if you do such a thing, then 
>>>>>> why do you even need inventory producers? FruDevice and PLDM 
>>>>>> could have hosted inventory on their own. If they still rely on 
>>>>>> the inventory producers (EM and PIM) with this "common interface" 
>>>>>> approach, then it's basically re-implementation/duplications of 
>>>>>> the (Inventory.Decorator.Asset like) interface by two processes.
>>>>
>>>> Richard, what is your thought on the re-implementation/duplication 
>>>> concern above? I'm not sure if you answered that and I missed.
>>> [Richard]: FRU Consumers must be aware about each and every Format 
>>> specifically, even though it conveys same meaning.
>>
>> I agree with that, but my question was about FRU producers.
>>
>>
>>>>> [Richard]: Basically FRU information (either IPMI/PLDM) is needed 
>>>>> for the inventory producers to expose configuration, which FRU 
>>>>> will not have. Say, based on FRU Product name, either we will 
>>>>> expose 4 temp sensor / 2 (Now along with this one, we need to 
>>>>> inform the product name through Inventory.Decorator.Asset). Now 
>>>>> from Redfish point of it, Inventory.Decorator is what it uses. 
>>>>> This is what i was asking with 2 options in earlier mail (whether 
>>>>> to change or stick with it (recommended)).
>>>>
>>>>>>
>>>>>> The idea is for apps like FruDevice and PLDM, which are aware of 
>>>>>> a specific FRU format, to host data in *that* format, to be 
>>>>>> consumed *solely* by inventory producers (like EM and PIM).
>>>>>>
>>>>> [Richard]: Yes, but it doesn't need to expose those in that format?
>>>>
>>>> Why not?
>>> [Richard]: What's the advantage in keeping it in that format itself?
>>
>> The advantage I see is basically what you said on the next line.
>>
>>> This is used only by EM / PIM, and not by redfish directly right? 
>>> Where the intelligence must reside in the producer or consumer (With 
>>> producer, consumers can be in common form)
>>
>>>>> Say Manufacturer Name, it doesn't mater whether it is coming from 
>>>>> PLDM FRU / IPMI FRU. Say we have a special handling for a 
>>>>> particular manufacture / product, then irrespective of inventory 
>>>>> producers both can handle the same.
>>>>
>>>> This is what the Inventory.Decorator.Asset interface is for.
>>> [Richard]: Yes, That is exposed by EM / PIM in our case. Why EM / 
>>> PIM must rely on 2 different stuff, for common things is the 
>>> question here.
>>>>
>>>>> If we have 2 different interface, then inventory producer may need 
>>>>> to be aware about both and probe it accordingly.
>>>>
>>>> No, the "FRU" properties producer needs to be concerned only about 
>>>> the format it understands.
>>>
>>> [Richard]: FRU property producer must know the format and produce 
>>> the interface with data (in common form as much as possible). E.g. 
>>> IPMI FRU Producer (say xyz.openbmc_project.FruDevice service) will 
>>> read device A FRU, and expose the Manufacturer name (It can read the 
>>> EEPROM content and decode it as per the IPMI FRU format, but the 
>>> data it produces is Manufacturer name). Simiarly PLDM FRU Producer 
>>> (say xyz.openbmc_project.PLDM.FruDevice service) will read the data 
>>> using PLDM FRU commands, and expose the Manufacturer name. Now why 
>>> this 2 service need to have 2 different interface(one from 
>>> Inventory.Source.PLDM & another from Inventory.Source.IPMI, to 
>>> expose the Manufacturer name. ? Why Entity manager / PIM need to 
>>> read the same information from 2 different interface and expose it 
>>> in Inventory.Decorator.Asset. (It can do it with same interface).
>>
>> What is that interface?
>
>
> @Richard - to elaborate further - on Gerrit you suggest moving things 
> like Serial Number and Part Number to Inventory.Decorator.Asset. 
> However, note that these are already present in 
> Inventory.Decorator.Asset. Hence the question - why do want FruDevice, 
> PLDM, EM, PIM to all implement Inventory.Decorator.Asset?
[Richard]:  No. What i meant was to use Inventory.Source.Common for 
serial Number, part number etc (Fru to Inventory) and inventory producer 
will use the inventory.Decorator.Asset for redfish exposure.
>
>
>>> What Entity manager / PIM needs to do is using Object Mapper query 
>>> all the FruDevices (IPMI / PLDM FRU), and accordingly expose the 
>>> Inventory
>>>>> FRU producers code must be written in such a way that for these 
>>>>> common properties it does the necessary conversion (Say make 
>>>>> manufacturer as string, irrespective of any format it read 
>>>>> through). Note: Specific stuff, we need to create a separate 
>>>>> interface (as phosphor-dbus-interface at present doesn't support 
>>>>> dynamic property addition/deletion). (Tomorrow, if we have any 
>>>>> other proprietary way of producing FRU data, we can still work 
>>>>> with this approach, with less or no change for other layers).
>>>>>
>>>>>> Also note that (as James pointed out in his email), the IPMI FRU 
>>>>>> format distinguishes Board/Chassis/Product areas. PLDM FRU format 
>>>>>> does not. So there are differences. If a new FRU format is 
>>>>>> introduced, then yes we would expect a new interface to show up 
>>>>>> under Inventory/Source/<FruFormat>
>>>>> [Richard]: Fru producers should do this conversion.
>>>>
>>>> I'm of the opinion that the inventory producer (like EM and PIM) 
>>>> should perform this conversion. Consider 
>>>> https://github.com/openbmc/entity-manager/blob/master/configurations/Intel%20Front%20Panel.json#L55 
>>>> for example. I don't think it's up to the FruDevice/PLDM kind of 
>>>> apps to decide that this is actually a Panel. You can design it 
>>>> that way, but like I said above that means the config knowledge 
>>>> moves into these apps, which I don't think we should head towards, 
>>>> since then every FRU producer app needs to do this. This is why we 
>>>> have apps like EM.
>>> [Richard]: Exactly. What we need to make sure is create abstraction 
>>> between Entity manager and FRU Producers as much as possible. FRU 
>>> Producer responsibility is to read the FRU in decode the FRU data as 
>>> per the spec and expose it in common form which Entity-manager / PIM 
>>> will rely on.
>>
>> I don't see why the abstraction is necessary. There already is 
>> abstraction in terms of the phosphor interfaces.
>>
>>>>> Say Chassis Type (Irrespective of what area it comes from it is 
>>>>> same). PLDM FRU mostly represents the product as a whole, but 
>>>>> technically we can point it to all the needed using the Fru Record 
>>>>> set to the Entity type mapping in the PDR record. Accordingly it 
>>>>> needs to be exposed.
>>>>>>
>>>>>>
>>>>>>> Yes, I am in favor of common interfaces for this where ever 
>>>>>>> possible.
>>>>>>>
>>>>>>> Is there someone that knows the existing FruDevice 
>>>>>>> implementation well
>>>>>>> enough that can be included in this work to propose common 
>>>>>>> interfaces
>>>>>>> where it is appropriate?
>>>>>>>
>>>>>>>> Inventory/Source/General/Fru (Maintain common things here 
>>>>>>>> Product Name.
>>>>>>>> This can be used by Inventory manager to advertise it (instead 
>>>>>>>> of searching
>>>>>>>> it in multiple interfaces/properties))
>>>>>>>
>>>>>>> Minor tweak here of 'Source/Common'?  When we have an existing 
>>>>>>> Inventory
>>>>>>> interface for this information should we mimic what is already in
>>>>>>> Inventory?  At some point are we trying to be too common that we're
>>>>>>> effectively reimplementing Inventory instances under a different 
>>>>>>> name?
>>>>>>>
>>>>> [Richard]: Yes, currently, FRU to inventory and inventory to upper 
>>>>> layer is what used. If we want to change it, we need to go with 
>>>>> differnt option of using FRU to upper layer, but many of existing 
>>>>> code will require change.
>>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> Richard
>>>>>
>>>>
>>
>

Re: D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager)

[Brad Bishop]

On Thu, 2020-05-28 at 07:03 -0500, Patrick Williams wrote:
> 
> After thinking about it for a bit, I think this is my preference with
> the design caveat that these are only consumed by processes which are
> "FRU-to-Inventory" transformers.  I would suggest putting these
> interfaces under the 'Inventory/' namespace somewhere to hopefully
> make this clearer.

> My suggestion would be to put these new proposed PLDM interfaces under
> `Inventory/Source/PLDM`.  Anything under `Source` becomes one of these
> "FRU-to-Inventory" transformational interfaces.

FWIW I'm also happy with this direction.  It would be great to get a
quick "me too" from the author of fru-device and entity-manager to avoid
wasting time later 😉

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

[James Feist]

On 5/28/2020 8:43 AM, Brad Bishop wrote:
> On Thu, 2020-05-28 at 07:03 -0500, Patrick Williams wrote:
>>
>> After thinking about it for a bit, I think this is my preference with
>> the design caveat that these are only consumed by processes which are
>> "FRU-to-Inventory" transformers.  I would suggest putting these
>> interfaces under the 'Inventory/' namespace somewhere to hopefully
>> make this clearer.
> 
>> My suggestion would be to put these new proposed PLDM interfaces under
>> `Inventory/Source/PLDM`.  Anything under `Source` becomes one of these
>> "FRU-to-Inventory" transformational interfaces.
> 
> FWIW I'm also happy with this direction.  It would be great to get a
> quick "me too" from the author of fru-device and entity-manager to avoid
> wasting time later 😉
> 

I don't have a strong opinion on the naming of the interface. That would 
be OK by me.