<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 24, 2019 at 10:13 AM Shawn McCarney <<a href="mailto:shawnmm@linux.vnet.ibm.com">shawnmm@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've reviewed both designs, although I cannot say I understand them both <br>
in depth.<br>
<br>
With that disclaimer, here is my 2 cents:<br>
<br>
* Both proposals are thoughtful with a lot work put into them.<br>
<br>
* bmcweb has a lot of a sensor code that is quite complex that is <br>
dependent on the current D-Bus sensors and associations.  It would <br>
require a lot of work and re-testing to ensure a different interface to <br>
sensor data doesn't break current systems.  The code would be even more <br>
complex if it had to support two different sensor data interfaces.<br>
<br>
* There are sensor readings that cannot be collected by reading files in <br>
the file system.  Some are collected by direct I2C reads or other <br>
methods.  If my surface understanding of collectd is correct, plug-ins <br>
would need to be written to handle these "non-file" sensors.<br>
<br>
* For the reasons above, I'd prefer to see D-Bus continue to be the <br>
"public API" to sensor data.  D-Bus is the central data sharing <br>
repository on the OpenBMC.  How the sensor data gets on D-Bus is <br>
implementation detail and can vary by system and by project.  It can be <br>
obtained by hwmon, collectd, and many other ways.  As long as it is <br>
published on D-Bus, other applications (like bmcweb) can easily consume it.<br>
<br>
* It sounds like the RRD format would be an efficient way to store <br>
sensor data.  I do worry about the space and CPU required to store <br>
telemetry data.  The OpenBMC stack is going to be used on some big <br>
servers, and they are going to have a large number of sensors.<br>
<br>
* Could the two proposals be merged, with D-Bus providing the public API <br>
to the data?  Maybe something like the following?  1) Continue to store <br>
current sensor values on D-Bus using the existing architecture.  Sensor <br>
values come from a variety of sources.  2) An application obtains <br>
current sensor values from D-Bus and stores them with timestamps in RRD <br>
to provide efficient history/telemetry.  3) A new D-Bus interface/method <br>
is created to obtain the history/telemetry data.  4) bmcweb uses the <br>
current D-Bus interfaces for the Sensor URIs (as it does today) and uses <br>
the new D-Bus interface/method for Telemetry URIs?<br>
<br>
Thanks,<br>
<br>
Shawn<br>
<br>
</blockquote></div><div><br></div>(author of the collectd/RRD based design here)<div>First of all, I have been silent on the mailing list for a while, without any progress on collectd. There are some fires that I need to put out first, unfortunately :(</div><div><br><div>I have discussed with Piotr in the telemetry meeting. Basically we'd like to rephrase it as this: Piotr's design doesn't prevent future extension such as using collectd/rrdtool as a backend to provide telemetry data, and I reviewed the Redfish API that the design would provide, which LGTM. Therefore I +1'ed Piotr's design, given that there is already concrete work behind it, and collectd didn't work for his requirements.</div><div><br></div><div>To be able to merge the designs, either Bmcweb can use RRD library or collectd/librrd can talk D-Bus, which is some work but not insurmountable. Piotr maybe you want to call that out explicitly in your design doc?</div><div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr">Regards,<div>Kun</div></div></div></div></div></div>