multiple telemetry designs

[Shawn McCarney]

I've reviewed both designs, although I cannot say I understand them both 
in depth.

With that disclaimer, here is my 2 cents:

* Both proposals are thoughtful with a lot work put into them.

* bmcweb has a lot of a sensor code that is quite complex that is 
dependent on the current D-Bus sensors and associations.  It would 
require a lot of work and re-testing to ensure a different interface to 
sensor data doesn't break current systems.  The code would be even more 
complex if it had to support two different sensor data interfaces.

* There are sensor readings that cannot be collected by reading files in 
the file system.  Some are collected by direct I2C reads or other 
methods.  If my surface understanding of collectd is correct, plug-ins 
would need to be written to handle these "non-file" sensors.

* For the reasons above, I'd prefer to see D-Bus continue to be the 
"public API" to sensor data.  D-Bus is the central data sharing 
repository on the OpenBMC.  How the sensor data gets on D-Bus is 
implementation detail and can vary by system and by project.  It can be 
obtained by hwmon, collectd, and many other ways.  As long as it is 
published on D-Bus, other applications (like bmcweb) can easily consume it.

* It sounds like the RRD format would be an efficient way to store 
sensor data.  I do worry about the space and CPU required to store 
telemetry data.  The OpenBMC stack is going to be used on some big 
servers, and they are going to have a large number of sensors.

* Could the two proposals be merged, with D-Bus providing the public API 
to the data?  Maybe something like the following?  1) Continue to store 
current sensor values on D-Bus using the existing architecture.  Sensor 
values come from a variety of sources.  2) An application obtains 
current sensor values from D-Bus and stores them with timestamps in RRD 
to provide efficient history/telemetry.  3) A new D-Bus interface/method 
is created to obtain the history/telemetry data.  4) bmcweb uses the 
current D-Bus interfaces for the Sensor URIs (as it does today) and uses 
the new D-Bus interface/method for Telemetry URIs?

Thanks,

Shawn