Handling State Sensor Association in Bmcweb

Handling State Sensor Association in Bmcweb

[Rohit Pai]

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

Hello Team,

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

  *   /xyz/openbmc_project/inventory/system/processors/CPU0


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
App1 :
   - /xyz/openbmc_project/inventory/system/processors/CPU0
        - xyz.openbmc_project.Inventory.Item.Cpu
            App2 (pldmd) :

   - /xyz/openbmc_project/inventory/system/processors/CPU0

        - xyz.openbmc_project.State.ProcessorPerformance
               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
App1 :
   - /xyz/openbmc_project/inventory/system/processors/CPU0
        - xyz.openbmc_project.Inventory.Item.Cpu
        - .Associations
              - all_states
                     - /xyz/openbmc_project/State/CPU0_Performance
            App2 (pldmd) :

   - /xyz/openbmc_project/State/CPU0_Performance

        - xyz.openbmc_project.State.ProcessorPerformance
               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,
Rohit PAI

[-- Attachment #2: Type: text/html, Size: 11042 bytes --]

Re: Handling State Sensor Association in Bmcweb

[Patrick Williams]

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

On Tue, Sep 06, 2022 at 03:46:25PM +0000, Rohit Pai wrote:
>                Option 2: There will be an explicit association defined between the inventory object and the state sensor object
> App1 :
>    - /xyz/openbmc_project/inventory/system/processors/CPU0
>         - xyz.openbmc_project.Inventory.Item.Cpu
>         - .Associations
>               - all_states
>                      - /xyz/openbmc_project/State/CPU0_Performance
>             App2 (pldmd) :
> 
>    - /xyz/openbmc_project/State/CPU0_Performance
> 
>         - xyz.openbmc_project.State.ProcessorPerformance
>                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.

Associations would be the preference.  The inventory tree should be
[mostly] static and non-changing.  Signals from this tree should be
relatively infrequent.

Generally, I think associations should be named using past participle
forms of speech.  So, 'all_states' probably isn't a name in line with
this.

-- 
Patrick Williams

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