multiple telemetry designs

[James Feist]

On 10/24/19 1:48 AM, Matuszczak, Piotr wrote:
> As for the two telemetry design proposals:
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/22257
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24357
> I talked with Kun and we agreed that a common bmcweb interface would be great in order to be able to support either the monitoring service or the collectd. In order to to do that collectd will have to be modified to expose D-Bus interface or bmcweb will have to support libraries to handle collectd directly. We at Intel prefer D-Bus for the OpenBMC architecture consistency.
> As for the implementation, we have monitoring service and Redfish telemetry service implemented (currently without triggers support), however it require some refactoring to be production code quality.

Is there a WIP review somewhere?

> 
> The Redfish Event Service (https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749) is something different than telemetry service, so I wouldn't consider it as third telemetry design. It is rather prepared to cooperate with the Redfish Telemetry Service and there is reference to telemetry design https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24357 .
> 
> -----Original Message-----
> From: Justin Thaler [mailto:thalerj at linux.vnet.ibm.com]
> Sent: Wednesday, October 23, 2019 10:30 PM
> To: James Feist <james.feist at linux.intel.com>; Brad Bishop <bradleyb at fuzziesquirrel.com>; Matuszczak, Piotr <piotr.matuszczak at intel.com>; kunyi at google.com; apparao.puli at linux.intel.com
> Cc: neladk at microsoft.com; openbmc at lists.ozlabs.org; Mihm, James <james.mihm at intel.com>
> Subject: Re: multiple telemetry designs
> 
> 
> 
> On 10/23/19 12:47 PM, James Feist wrote:
>> On 10/23/19 10:39 AM, James Feist wrote:
>>> On 10/23/19 9:38 AM, Brad Bishop wrote:
>>>> There are two telemetry / metric designs under review right now:
> 
> There's a fourth option that can also be used, but more than just sensor readings. This isn't redfish compliant and relies on secure websockets however.
> 
> https://github.com/openbmc/docs/blob/master/rest-api.md#event-subscription-protocol
> 
>>
>> I've been informed there are actually 3:
>>
>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749
>>
>> Added Appu to this conversation as well.
>>
>>
>>>>
>>>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/22257
>>>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24357
>>>>
>>>> I would like to see one or both of them merged.  Neither seem to
>>>> have any support….there is a single +1 on the latter review from
>>>> Shawn McCarney.  If you support one of these designs, please go
>>>> review it and indicate your support.
>>>
>>> It looks like Kun has +1ed Piotr's design as well, not sure if that
>>> means we can go with one design?
>>>
>>>>
>>>> I also can’t figure out what the path forward for OpenBMC is.  Maybe
>>>> to start with, we could all level set on where we are at with our
>>>> thinking:
>>>>
>>>> Kun: How far along are you in the implementation of your proposal?
>>>> Piotr: How far along are you in the implementation of your proposal?
>>>> James: OpenBMC can support one or both proposals.  If we support
>>>> both, this means multiple implementations for the same thing in
>>>> bmcweb.  One that gets data from dbus objects, and another that gets
>>>> it from librrd.  As the maintainer of bmcweb are you open to
>>>> accepting one or both of these options?
>>>
>>> With 0 previous knowledge, I would suggest using a way that works
>>> with previous OBMC practices, and that is using dbus. If there has to
>>> be 2 separate designs, then if both produce the same d-bus
>>> interfaces, it shouldn't matter to bmcweb which one is being used.
>>> That being said, if this doesn't work for some reason, we've used
>>> compile switches in the past, although this would be the least preferable option.
>>> Truthfully I haven't looked at these designs yet as I've only
>>> recently taken a larger role in bmcweb reviews, so I'll try to look at them soon.
>>>
>>>
>>>>
>>>> Without any discussion and resolution, I’m afraid both of these
>>>> proposals are just going to sit here, unmerged, indefinitely.
>>>>
>>>> thx - brad
>>>>