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