No sensors displayed in webUI

[Lei YU]

On Thu, Jan 16, 2020 at 4:46 AM James Feist <james.feist at 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=
> >