PSU Sensors - Associations

[Patrick Venture]

On Wed, Oct 23, 2019 at 11:00 AM James Feist
<james.feist at linux.intel.com> wrote:
>
> On 10/23/19 10:56 AM, Patrick Venture wrote:
> > On Wed, Oct 23, 2019 at 10:54 AM James Feist
> > <james.feist at linux.intel.com> wrote:
> >>
> >> On 10/23/19 10:52 AM, Patrick Venture wrote:
> >>> On Wed, Oct 23, 2019 at 10:50 AM James Feist
> >>> <james.feist at linux.intel.com> wrote:
> >>>>
> >>>> On 10/23/19 10:37 AM, Patrick Venture wrote:
> >>>>> So, I flipped the association interface addition and the property
> >>>>> initialization to match other sensors, and then it started working.  I
> >>>>> was curious if you had any suggestions on how to find the matching
> >>>>> sensor given the paths, for instance:
> >>>>>
> >>>>> busctl get-property xyz.openbmc_project.PSUSensor
> >>>>> /xyz/openbmc_project/sensors/temperature/alt2_Temperature
> >>>>> xyz.openbmc_project.Association.Definitions Associations
> >>>>> a(sss) 1 "chassis" "all_sensors"
> >>>>> "/xyz/openbmc_project/inventory/system/board/Altie"
> >>>>>
> >>>>> busctl tree --no-pager xyz.openbmc_project.EntityManager|grep Altie
> >>>>>              |-/xyz/openbmc_project/inventory/system/board/Altie
> >>>>>              | |-/xyz/openbmc_project/inventory/system/board/Altie/al_temp_0
> >>>>>              | |-/xyz/openbmc_project/inventory/system/board/Altie/al_temp_1
> >>>>>              | |-/xyz/openbmc_project/inventory/system/board/Altie/al_temp_2
> >>>>>              | `-/xyz/openbmc_project/inventory/system/board/Altie/alt1
> >>>>>
> >>>>> No alt2 -- so how do I know this?  I can walk every subordinate object
> >>>>> to find the name match, but I was curious if you had a faster idea?
> >>>>
> >>>> So for the associations you should generally not look at the definition,
> >>>> the definition is primarily for the mapper. You should be looking in the
> >>>> mapper for the association that matches the sensor name that you care
> >>>> about and it should point back to the configuration. If there are not
> >>>> associations for each of the sub-sensors, there should be.
> >
> > I took a look at the ObjectMapper interface you mentioned, and it just
> > points to the Board, not the individual sensor from the board.
> >
> >>>
> >>> I must have looked at the wrong entry there because I didn't see
> >>> anything pointing back to the sensor config entry, but just the sensor
> >>> itself.  I'll take a look now, the PSU sensor naming issue is
> >>> identical to the one if there is just another name available or the
> >>> Pwm case.
> >>
> >> Ah you're right, I don't that that is implemented. Should we create a
> >> new association for this? It seems useful.
> >
> > Not that I don't love hearing that I'm right, but in this case I would
> > have rather been wrong and there been a magic bullet in place that I
> > had overlooked.
> >
> > I think all of my association mapping woes would immediately go away
> > if every sensor pointed to the configuration dbus object that brought
> > it to life.
>
> My original argument was to have the association to point to the
> configuration item, but I got overruled when trying to add it to bmcweb,
> as bmcweb cares what 'chassis' an item is in. I would have preferred
> pointing to the item that brought it to life, but then to find the
> chassis you need to go up one element in the path. That being said, it
> would be a small change to support both.

I'm perfectly happy to see this change come into the world.  It would
wipe away three cases I have that otherwise have to be solved with
slow exhaustive search :)

>
>
> >
> >>
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Patrick
> >>>>>