Create association between dbus object probed by entity manager and the ones it generated

[wltu]

We want a clear association between the dbus object that the EntityManager probed from so that we have a simple way to lookup the entity manager dbus object from the probed object.

There are instances where the EntityManager dbus object has more information that is configured in the json file and we want to fetch that information when we only know the probed dbus object.

This is an attempt to resolve https://github.com/openbmc/phosphor-host-ipmid/blob/8c974f76411cb40f2c9c25cddd86814087d0eddf/dbus-sdr/storagecommands.cpp#L597

Current Algorithm

For each Fru Sdr, we will call GetManagedObject from EntityManager service, we know the Fru bus and address, it will compare to all objects and then get the EntityInstance + EntityId from the same object to populate to the ipmi response.

The information needed is something configured in EntityMangaer like

    "xyz.openbmc_project.Inventory.Decorator.Ipmi": {
        "EntityId": "0x0B",
        "EntityInstance": "$BUS"
    },

this information shouldn't be in the FruDevice service directly so it is generated by EntityManager instead.

Proposal

For each dbus object created by EntityManager, we will create a probed_from/generated association between the services. This will allow us to lookup the EntityManager dbus object from the dbus FruDevice.

This will change the ipmid fru sdr fetch to

• ipmid detects the fru from FruDevice
• Checks the generated association to find the EntityManager object
• Get the information needed.

[williamspatrick]

I think @pointbazaar was looking into something similar also.

[williamspatrick]

@wltu Are you wanting to walk this association from code? It kind of sounds like it. The FruDevice stuff really should be considered “internal to entity manager” and we should start picking apart pieces from other applications. What is driving needing this additional data? Shouldn’t you just add that data to you EM config?

[williamspatrick]

ipmid detects the fru from FruDevice

Ack! What? Why are we doing this as is?

[edtanous]

@wltu what is the end goal here? Debug? User facing API?

The FRU device API isn’t the most structured (being ported from a python script to C++ way back when). EM is the “filter” that’s supposed to turn a bunch of random decided fields into a well formed interface.

[pointbazaar]

I think if it improves overall performance these associations may be a good idea.

I think @pointbazaar was looking into something similar also.

Yes, but i wanted to prioritize the schema cleanup before adding additional complexity into the EM.

Checks the generated association to find the EntityManager object

What if there are multiple entries for "generated", what does the code do then?

Forgive me if i don't have much of an overview of EntityId and EntityInstance, I'm not using ipmi much these days.

[pointbazaar]

Update: probe association patch is available https://gerrit.openbmc.org/c/openbmc/entity-manager/+/82615