multiple telemetry designs

[Justin Thaler]

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
>>>