<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">This is great discussion. can we have a deep dive on this during next telemetry sync up call ?
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Neeraj<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> Kun Yi <kunyi@google.com> <br>
<b>Sent:</b> Thursday, October 24, 2019 10:27 AM<br>
<b>To:</b> Shawn McCarney <shawnmm@linux.vnet.ibm.com><br>
<b>Cc:</b> Brad Bishop <bradleyb@fuzziesquirrel.com>; James Feist <james.feist@linux.intel.com>; piotr.matuszczak@intel.com; thalerj@linux.vnet.ibm.com; OpenBMC Maillist <openbmc@lists.ozlabs.org>; james.mihm@intel.com; Neeraj Ladkani <neladk@microsoft.com><br>
<b>Subject:</b> Re: multiple telemetry designs<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">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<o:p></o:p></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">(author of the collectd/RRD based design here)<o:p></o:p></p>
<div>
<p class="MsoNormal">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 :(<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<div>
<p class="MsoNormal">Kun<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>