multiple telemetry designs

James Feist james.feist at linux.intel.com
Thu Oct 24 04:47:24 AEDT 2019


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:

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


More information about the openbmc mailing list