Handling State Sensor Association in Bmcweb
ropai at nvidia.com
Wed Sep 7 01:46:25 AEST 2022
This email is to discuss the implementation details regarding state sensors association with inventory objects when multiple applications are involved.
On our platform, we have a service that populates different inventory objects like CPU, GPU, Power Supply, Memory, etc.
For example, let's say there is a CPU instance that is represented over dbus like below
Then we have another application that hosts state sensor information related to this CPU0 instance.
To be more specific the second application is the pldm daemon which reads all the state sensor information related to this CPU.
These are discrete sensors that are represented using unique dbus interfaces.
Example (dbus interface)
* CPU throttle state (xyz.openbmc_project.State.ProcessorPerformance)
* CPU power supply reg state (xyz.openbmc_project.State.Decorator.PowerSystemInputs)
Now in the above case if I must associate the state sensor (from Pldm) with the inventory object (from a different app) then what would be a preferred way?
My end goal is to get these state sensors over redfish and association will help me identify the relation between the entities and the sensor data.
Few thoughts which are in my mind
Option 1: Both applications use the exact same dbus object path
App2 (pldmd) :
Bmcweb uses the object mapper to get the object path which implements the required dbus interface and then will identity the CPU0 instance from the object path.
Option 2: There will be an explicit association defined between the inventory object and the state sensor object
App2 (pldmd) :
New keyword 'all_states' is used as an association string.
Bmcweb will use this association to find the object path of the state sensor which implements the state sensor which belongs to the CPU0 instance.
This pattern is very similar to how the numeric sensor code is working today.
Please provide your thoughts/preferences regarding the options.
Comment If there are other ways to solve the same problem.
Thanks and Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc