All of lore.kernel.org
 help / color / mirror / Atom feed
* No sensors displayed in webUI
       [not found] <138261238.19427827.1579077694127.ref@mail.yahoo.com>
@ 2020-01-15  8:41 ` Max Power
  2020-01-15 17:26   ` James Feist
  2020-01-21  8:17   ` Max Power
  0 siblings, 2 replies; 9+ messages in thread
From: Max Power @ 2020-01-15  8:41 UTC (permalink / raw)
  To: openbmc

Hi

What are the basic requirements for phosphor-webui to display the list
the available sensors?

I've create a simple entity-manager configuration for my custom hardware
containing some voltage and temp sensors definitions. All the configured
sensors are accessible under "/sys/class/hwmon/hwmon*".
"entity-manager" and "dbus-sensors" related services like "ADCSensor" or
"CPUSensor" are up and running, "busctl tree" lists all the sensors
under "/xyz/openbmc_project/sensors" and I'm able to read the sensors
properities using "busctl introspect".

But the server-health/sensors-overview page in webUI always shows 
"There are no sensors found."

Any hints or ideas what I am missing?
Do I need any other services running besides "entity-manger" and
"dbus-sensors"?

Max

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-15  8:41 ` No sensors displayed in webUI Max Power
@ 2020-01-15 17:26   ` James Feist
  2020-01-15 19:27     ` Patrick Williams
  2020-01-21  8:17   ` Max Power
  1 sibling, 1 reply; 9+ messages in thread
From: James Feist @ 2020-01-15 17:26 UTC (permalink / raw)
  To: Max Power, openbmc

On 1/15/20 12:41 AM, Max Power wrote:
> Hi
> 
> What are the basic requirements for phosphor-webui to display the list
> the available sensors?
> 
> I've create a simple entity-manager configuration for my custom hardware
> containing some voltage and temp sensors definitions. All the configured
> sensors are accessible under "/sys/class/hwmon/hwmon*".
> "entity-manager" and "dbus-sensors" related services like "ADCSensor" or
> "CPUSensor" are up and running, "busctl tree" lists all the sensors
> under "/xyz/openbmc_project/sensors" and I'm able to read the sensors
> properities using "busctl introspect".
> 
> But the server-health/sensors-overview page in webUI always shows
> "There are no sensors found."

There was a thread about this last week:

https://lists.ozlabs.org/pipermail/openbmc/2020-January/020044.html
https://lists.ozlabs.org/pipermail/openbmc/2020-January/020136.html

TL;DR all the sensors are available in Redfish, but the WebUI hasn't 
move over to full Redfish support yet. There is a test patch that helps 
enable this in the thread.



> 
> Any hints or ideas what I am missing?
> Do I need any other services running besides "entity-manger" and
> "dbus-sensors"?
> 
> Max
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-15 17:26   ` James Feist
@ 2020-01-15 19:27     ` Patrick Williams
  2020-01-15 20:45       ` James Feist
  0 siblings, 1 reply; 9+ messages in thread
From: Patrick Williams @ 2020-01-15 19:27 UTC (permalink / raw)
  To: James Feist; +Cc: Max Power, openbmc

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

On Wed, Jan 15, 2020 at 09:26:48AM -0800, James Feist wrote:
> There was a thread about this last week:
> 
> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020044.html
> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020136.html
> 
> TL;DR all the sensors are available in Redfish, but the WebUI hasn't move
> over to full Redfish support yet. There is a test patch that helps enable
> this in the thread.

Hi James,

This statement about a dependency on Redfish stood out to me.  The
current UI is mostly using the "old" REST API, but as long as the dbus
objects are created correctly it should not matter one bit if the
external interface is the dbus-based REST API or the Redfish one.

This is a bug in dbus-sensors that is independent of Redfish vs REST.

The current webui code expects there to be properties that are specified
in phosphor-dbus-interfaces.  Specifically, it is looking for the "Unit"
property[1], which is a required property on
xyz.openbmc_project.Sensor.Value[2].  The dbus-sensors has a bunch of
Sensor.Value objects that are violating the interface spec by not
providing "Unit" [3].  Notice that `setInitialProperties` doesn't
register_property on "Unit" and neither does any other code in this
repository[4].

Why is none of this code using the code generated from
phosphor-dbus-interfaces?  Since it is generating dbus objects "by
hand" it isn't not getting any compile-time checking if it is doing the
wrong thing (or more likely that the phosphor-dbus-interface changes out
from underneath it).

[1] https://github.com/openbmc/phosphor-webui/blob/f70f42553615972163b36c9b4d77be07e4399122/app/common/services/api-utils.js#L979
[2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Value.interface.yaml#L32
[3] https://github.com/openbmc/dbus-sensors/blob/fbb44ad1ea716d4e8c2cacdf01d380c6d0f53855/include/sensor.hpp#L13
[4] https://github.com/openbmc/dbus-sensors/search?utf8=%E2%9C%93&q=unit&type=

-- 
Patrick Williams

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-15 19:27     ` Patrick Williams
@ 2020-01-15 20:45       ` James Feist
  2020-01-16  2:33         ` Lei YU
  0 siblings, 1 reply; 9+ messages in thread
From: James Feist @ 2020-01-15 20:45 UTC (permalink / raw)
  To: Patrick Williams; +Cc: Max Power, openbmc

On 1/15/20 11:27 AM, Patrick Williams wrote:
> On Wed, Jan 15, 2020 at 09:26:48AM -0800, James Feist wrote:
>> There was a thread about this last week:
>>
>> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020044.html
>> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020136.html
>>
>> TL;DR all the sensors are available in Redfish, but the WebUI hasn't move
>> over to full Redfish support yet. There is a test patch that helps enable
>> this in the thread.
> 
> Hi James,
> 
> This statement about a dependency on Redfish stood out to me.  The
> current UI is mostly using the "old" REST API, but as long as the dbus
> objects are created correctly it should not matter one bit if the
> external interface is the dbus-based REST API or the Redfish one.
> 
> This is a bug in dbus-sensors that is independent of Redfish vs REST.
> 
> The current webui code expects there to be properties that are specified
> in phosphor-dbus-interfaces.  Specifically, it is looking for the "Unit"
> property[1], which is a required property on
> xyz.openbmc_project.Sensor.Value[2].  The dbus-sensors has a bunch of
> Sensor.Value objects that are violating the interface spec by not
> providing "Unit" [3].  Notice that `setInitialProperties` doesn't
> register_property on "Unit" and neither does any other code in this
> repository[4].
> 
> Why is none of this code using the code generated from
> phosphor-dbus-interfaces?  Since it is generating dbus objects "by
> hand" it isn't not getting any compile-time checking if it is doing the
> wrong thing (or more likely that the phosphor-dbus-interface changes out
> from underneath it).

There is a long history of this where I tried to get everyone to update 
the sensor value interface to use double instead of INT. I had a large 
agreement, but unfortunately updating all of the daemons that we did not 
use (and without any good way of testing), and trying to get by-in or 
help from all the maintainers became too large of a job. I updated as 
many daemons as I could to accept both before I ran out of time. At the 
same time, I was also phasing out unit, as unit was easy enough to read 
from the sensor path, and redundant information. All of our internal 
daemons don't use phosphor-dbus-interfaces to create interfaces, as we 
have found the code generation difficult to explain to new users, and it 
also makes it difficult to upgrade daemons as all patches need to be 
merged at once. We have been updating interfaces for documentation 
purposes, but haven't used them for any new work in quite some time.


> 
> [1] https://github.com/openbmc/phosphor-webui/blob/f70f42553615972163b36c9b4d77be07e4399122/app/common/services/api-utils.js#L979
> [2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Value.interface.yaml#L32
> [3] https://github.com/openbmc/dbus-sensors/blob/fbb44ad1ea716d4e8c2cacdf01d380c6d0f53855/include/sensor.hpp#L13
> [4] https://github.com/openbmc/dbus-sensors/search?utf8=%E2%9C%93&q=unit&type=
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-15 20:45       ` James Feist
@ 2020-01-16  2:33         ` Lei YU
  0 siblings, 0 replies; 9+ messages in thread
From: Lei YU @ 2020-01-16  2:33 UTC (permalink / raw)
  To: James Feist; +Cc: Patrick Williams, Max Power, OpenBMC Maillist

On Thu, Jan 16, 2020 at 4:46 AM James Feist <james.feist@linux.intel.com> wrote:
>
> On 1/15/20 11:27 AM, Patrick Williams wrote:
> > On Wed, Jan 15, 2020 at 09:26:48AM -0800, James Feist wrote:
> >> There was a thread about this last week:
> >>
> >> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020044.html
> >> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020136.html
> >>
> >> TL;DR all the sensors are available in Redfish, but the WebUI hasn't move
> >> over to full Redfish support yet. There is a test patch that helps enable
> >> this in the thread.
> >
> > Hi James,
> >
> > This statement about a dependency on Redfish stood out to me.  The
> > current UI is mostly using the "old" REST API, but as long as the dbus
> > objects are created correctly it should not matter one bit if the
> > external interface is the dbus-based REST API or the Redfish one.
> >
> > This is a bug in dbus-sensors that is independent of Redfish vs REST.
> >
> > The current webui code expects there to be properties that are specified
> > in phosphor-dbus-interfaces.  Specifically, it is looking for the "Unit"
> > property[1], which is a required property on
> > xyz.openbmc_project.Sensor.Value[2].  The dbus-sensors has a bunch of
> > Sensor.Value objects that are violating the interface spec by not
> > providing "Unit" [3].  Notice that `setInitialProperties` doesn't
> > register_property on "Unit" and neither does any other code in this
> > repository[4].
> >
> > Why is none of this code using the code generated from
> > phosphor-dbus-interfaces?  Since it is generating dbus objects "by
> > hand" it isn't not getting any compile-time checking if it is doing the
> > wrong thing (or more likely that the phosphor-dbus-interface changes out
> > from underneath it).
>
> There is a long history of this where I tried to get everyone to update
> the sensor value interface to use double instead of INT. I had a large
> agreement, but unfortunately updating all of the daemons that we did not
> use (and without any good way of testing), and trying to get by-in or
> help from all the maintainers became too large of a job. I updated as
> many daemons as I could to accept both before I ran out of time. At the
> same time, I was also phasing out unit, as unit was easy enough to read
> from the sensor path, and redundant information. All of our internal
> daemons don't use phosphor-dbus-interfaces to create interfaces, as we
> have found the code generation difficult to explain to new users, and it
> also makes it difficult to upgrade daemons as all patches need to be
> merged at once. We have been updating interfaces for documentation
> purposes, but haven't used them for any new work in quite some time.
>

This is really an issue.
Typically an OpenBMC service will use the data types defined in
phosphor-dbus-interface, when it does not, it causes such trouble:

When I worked on a change in bmcweb to update some sensor value, it's
found that bmcweb is not using the correct type causing runtime D-Bus
exception.
And the code has to be changed to handle both types, where one is
defined in phosphor-dbus-interface, and the other is un-documented.

It's really appreciated if we could use the unified interface.

>
> >
> > [1] https://github.com/openbmc/phosphor-webui/blob/f70f42553615972163b36c9b4d77be07e4399122/app/common/services/api-utils.js#L979
> > [2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Value.interface.yaml#L32
> > [3] https://github.com/openbmc/dbus-sensors/blob/fbb44ad1ea716d4e8c2cacdf01d380c6d0f53855/include/sensor.hpp#L13
> > [4] https://github.com/openbmc/dbus-sensors/search?utf8=%E2%9C%93&q=unit&type=
> >

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-15  8:41 ` No sensors displayed in webUI Max Power
  2020-01-15 17:26   ` James Feist
@ 2020-01-21  8:17   ` Max Power
  2020-01-21 19:02     ` James Feist
  1 sibling, 1 reply; 9+ messages in thread
From: Max Power @ 2020-01-21  8:17 UTC (permalink / raw)
  To: openbmc; +Cc: James Feist, Patrick Williams, Lei YU

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

 Thank you all for your explanations.

Any chance to get the "bug in dbus-sensors" fixed in the near future?

Max
  

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-21  8:17   ` Max Power
@ 2020-01-21 19:02     ` James Feist
  2020-01-21 23:00       ` Gunnar Mills
  0 siblings, 1 reply; 9+ messages in thread
From: James Feist @ 2020-01-21 19:02 UTC (permalink / raw)
  To: Max Power, openbmc

On 1/21/20 12:17 AM, Max Power wrote:
> Thank you all for your explanations.
> 
> Any chance to get the "bug in dbus-sensors" fixed in the near future?

I have no plans on changing dbus-sensors, since this works with Redfish, 
and Redfish is the future back-end for the WebUI. I'd be fine if someone 
wants to add unit support for an intermediate fix. That or we could 
finish this patch and get the WebUI moved over.

https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/28342

> 
> Max

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-21 19:02     ` James Feist
@ 2020-01-21 23:00       ` Gunnar Mills
  2020-01-21 23:50         ` James Feist
  0 siblings, 1 reply; 9+ messages in thread
From: Gunnar Mills @ 2020-01-21 23:00 UTC (permalink / raw)
  To: James Feist, Max Power, openbmc


On 1/21/2020 1:02 PM, James Feist wrote:
> On 1/21/20 12:17 AM, Max Power wrote:
>>
>> Any chance to get the "bug in dbus-sensors" fixed in the near future?
>
> I have no plans on changing dbus-sensors, since this works with 
> Redfish, and Redfish is the future back-end for the WebUI. I'd be fine 
> if someone wants to add unit support for an intermediate fix. That or 
> we could finish this patch and get the WebUI moved over.
>
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/28342
>

I support moving the WebUI to Redfish but moving the sensor page to 
Redfish, I feel hides the actual problem.
I think we should follow the phosphor-dbus-interfaces.

If we don't follow the interfaces, how when writing code, whether 
phoshor-webui code or bmcweb code, do you know what to expect?

If "Unit" is redundant information, then I feel it should be removed 
from phosphor-dbus-interfaces and stricter requirements on the sensor 
path should be added.

See https://lists.ozlabs.org/pipermail/openbmc/2020-January/020207.html

Thanks!
Gunnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No sensors displayed in webUI
  2020-01-21 23:00       ` Gunnar Mills
@ 2020-01-21 23:50         ` James Feist
  0 siblings, 0 replies; 9+ messages in thread
From: James Feist @ 2020-01-21 23:50 UTC (permalink / raw)
  To: Gunnar Mills, Max Power, openbmc

On 1/21/20 3:00 PM, Gunnar Mills wrote:
> 
> On 1/21/2020 1:02 PM, James Feist wrote:
>> On 1/21/20 12:17 AM, Max Power wrote:
>>>
>>> Any chance to get the "bug in dbus-sensors" fixed in the near future?
>>
>> I have no plans on changing dbus-sensors, since this works with 
>> Redfish, and Redfish is the future back-end for the WebUI. I'd be fine 
>> if someone wants to add unit support for an intermediate fix. That or 
>> we could finish this patch and get the WebUI moved over.
>>
>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/28342
>>
> 
> I support moving the WebUI to Redfish but moving the sensor page to 
> Redfish, I feel hides the actual problem.
> I think we should follow the phosphor-dbus-interfaces.

I tried to update the interface, but last time I got hit with that I had 
to prove that witherspoon fan control still worked without having access 
to such a system, and the Qemu model didn't offer sensor scanning. This 
was after I'd already spent a large amount of time getting buy-in.

> 
> If we don't follow the interfaces, how when writing code, whether 
> phoshor-webui code or bmcweb code, do you know what to expect?
> 
> If "Unit" is redundant information, then I feel it should be removed 
> from phosphor-dbus-interfaces and stricter requirements on the sensor 
> path should be added.

I'm fine with someone adding Unit if they need it.

> 
> See https://lists.ozlabs.org/pipermail/openbmc/2020-January/020207.html
> 
> Thanks!
> Gunnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-01-21 23:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <138261238.19427827.1579077694127.ref@mail.yahoo.com>
2020-01-15  8:41 ` No sensors displayed in webUI Max Power
2020-01-15 17:26   ` James Feist
2020-01-15 19:27     ` Patrick Williams
2020-01-15 20:45       ` James Feist
2020-01-16  2:33         ` Lei YU
2020-01-21  8:17   ` Max Power
2020-01-21 19:02     ` James Feist
2020-01-21 23:00       ` Gunnar Mills
2020-01-21 23:50         ` James Feist

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.