PSU Sensors - Associations

PSU Sensors - Associations

[Patrick Venture]

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?

Thanks,
Patrick

Re: PSU Sensors - Associations

[James Feist]

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.

> 
> Thanks,
> Patrick
> 

Re: PSU Sensors - Associations

[Patrick Venture]

On Wed, Oct 23, 2019 at 10:50 AM James Feist
<james.feist@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 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.
>
> >
> > Thanks,
> > Patrick
> >

Re: PSU Sensors - Associations

[James Feist]

On 10/23/19 10:52 AM, Patrick Venture wrote:
> On Wed, Oct 23, 2019 at 10:50 AM James Feist
> <james.feist@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 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.

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

Re: PSU Sensors - Associations

[Patrick Venture]

On Wed, Oct 23, 2019 at 10:54 AM James Feist
<james.feist@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@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.

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

Re: PSU Sensors - Associations

[James Feist]

On 10/23/19 10:56 AM, Patrick Venture wrote:
> On Wed, Oct 23, 2019 at 10:54 AM James Feist
> <james.feist@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@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.


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

Re: PSU Sensors - Associations

[Patrick Venture]

On Wed, Oct 23, 2019 at 11:00 AM James Feist
<james.feist@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@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@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
> >>>>>

Re: PSU Sensors - Associations

[Lei YU]

On Thu, Oct 24, 2019 at 1:39 AM Patrick Venture <venture@google.com> 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?

It looks like buggy, I think mapper shall make sure the association
object is created only when the associated object exists.
@Matt Spinler could you confirm that?

Re: PSU Sensors - Associations

[Matt Spinler]

On 10/23/2019 9:03 PM, Lei YU wrote:
> On Thu, Oct 24, 2019 at 1:39 AM Patrick Venture <venture@google.com> 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?
> It looks like buggy, I think mapper shall make sure the association
> object is created only when the associated object exists.
> @Matt Spinler could you confirm that?

I'm not entirely following  what the problem is here, but I will still 
take a moment
to plug my association (and other mapper functionality) documentation at:
https://github.com/openbmc/docs/blob/master/architecture/object-mapper.md#associations

Re: PSU Sensors - Associations

[Patrick Venture]

On Thu, Oct 24, 2019 at 6:07 AM Matt Spinler <mspinler@linux.ibm.com> wrote:
>
>
>
> On 10/23/2019 9:03 PM, Lei YU wrote:
> > On Thu, Oct 24, 2019 at 1:39 AM Patrick Venture <venture@google.com> 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?
> > It looks like buggy, I think mapper shall make sure the association
> > object is created only when the associated object exists.
> > @Matt Spinler could you confirm that?
>
> I'm not entirely following  what the problem is here, but I will still
> take a moment
> to plug my association (and other mapper functionality) documentation at:
> https://github.com/openbmc/docs/blob/master/architecture/object-mapper.md#associations

Thanks, so given the documentation, we can create additional endpoints
because there is more than one relationship with the object.

>

Re: PSU Sensors - Associations

[Shawn McCarney]

Hi,

I didn't follow all of your terminology, so I might be off base here, 
but in case it helps ...

There are two associations to power supply sensors from a Redfish/bmcweb 
perspective:

* chassis <-> all sensors in chassis (including PSU sensors).  This is 
needed because Redfish output is for a specific chassis.  We only want 
sensors (including PSU sensors) from the specified chassis.

* PSU inventory item <-> all sensors for the PSU.  This is used in 
several ways.  First, it allows us to store multiple PSU sensor values 
in a single associated Redfish PowerSupply object (PowerInputWatts, 
PowerOutputWatts).  Second, it allows us to look at the status of the 
PSU inventory item (e.g. is it functional? present?) when setting the 
status of the Redfish PSU sensor. Lastly, it allows us to access the VPD 
(PartNumber, SerialNumber) of the PSU inventory item associated with a 
PSU sensor.

This is documented here: 
https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#redfish

If not relevant, sorry please ignore ...

Shawn