Location Codes in Entity Manager

[Matt Spinler]

Hi,

We're trying to see if we can move from splitting our inventory needs
between entity-manager and phosphor-inventory into just using EM.

One thing we used PIM for was holding our
xyz.openbmc_project.Inventory.Decorator.LocationCode values, which are 
used to
hierarchically identify a specific connector in the system. This applies to
both internal and external connectors. Several apps make use of them, for
example bmcweb to populate the ServiceLabel property or PLDM to send 
location
codes to the BIOS.

The base of our location code is built with the chassis SN and some 
other values,
and below I'll just refer to it as 'BASE'.  Here are some examples:

BASE
   - chassis location code
BASE-P0
   - the backplane connector on the chassis
BASE-P0-C0
   - the leftmost card connector on the backplane
BASE-P0-C0-T1
   - an ethernet connector on that card

As these point to connectors, they still need to be populated regardless 
of the
presence of what's plugged into the connector.  No location codes downstream
from an absent card are needed (i.e. if no P0-C0 card is populated then
there is no concept of a P0-C0-T1).

Does it make sense to have EM host these interfaces? It seems to fit pretty
naturally, with a few enhancements:

- Come up with a connector model such that Inventory.* D-Bus interfaces 
can be
   created for connectors on an entity.  While I see mentions of 
connectors in
   the Exposes array for use with fans, currently everything in Exposes only
   emits .Configuration. interfaces. Aside from just the location code 
interface
   we'd want the Inventory.Item.Connector interface (or maybe instead 
one that
   identifies the type of connector), and a name property.

- Match up a card with its parent connector, including when there are 
multiple
   connectors the card can plug into (like pcie cards), so that the 
child card
   can obtain its location code from the connector so it can make it 
available
   to its children.  The physical topology code in EM can create 
associations
   between parent and child entities, so it would add on to that and add
   connector associations as well, plus the ability to pull data from the
   connector to use.

- Come up with a concept of a location code base.  Maybe just some new JSON
   syntax that could be used (in the chassis JSON file in our case) that 
says
   where to get it from D-Bus which can then get propagated through the 
model.

Is this the right direction?  If so, any ideas on the modeling?

Thanks!