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