All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Feist <james.feist@linux.intel.com>
To: Brad Bishop <bradleyb@fuzziesquirrel.com>,
	piotr.matuszczak@intel.com, kunyi@google.com,
	apparao.puli@linux.intel.com
Cc: thalerj@linux.vnet.ibm.com, openbmc@lists.ozlabs.org,
	james.mihm@intel.com, neladk@microsoft.com
Subject: Re: multiple telemetry designs
Date: Wed, 23 Oct 2019 10:47:24 -0700	[thread overview]
Message-ID: <8998b51b-4e67-738e-becd-63c26ea626be@linux.intel.com> (raw)
In-Reply-To: <dd81fb28-4d01-8726-9b16-81a677eb3e16@linux.intel.com>

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

  reply	other threads:[~2019-10-23 17:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 16:38 multiple telemetry designs Brad Bishop
2019-10-23 17:39 ` James Feist
2019-10-23 17:47   ` James Feist [this message]
2019-10-23 20:30     ` Justin Thaler
2019-10-24  8:48       ` Matuszczak, Piotr
2019-10-24 16:14         ` James Feist
2019-10-25 12:07           ` Brad Bishop
2019-10-25 16:46             ` Matuszczak, Piotr
2019-10-25 16:59               ` Brad Bishop
2019-10-28 16:35                 ` Matuszczak, Piotr
2019-10-28 16:42                   ` Brad Bishop
2019-11-05  7:31                     ` vishwa
2019-11-05  8:56                       ` Matuszczak, Piotr
2019-11-05 16:58                         ` vishwa
2019-11-12 14:36                           ` Justin Thaler
2019-11-12 14:39                             ` Paul Vancil
2019-11-14 16:37                               ` Matuszczak, Piotr
2019-10-24 17:13 ` Shawn McCarney
2019-10-24 17:27   ` Kun Yi
2019-10-24 17:31     ` Neeraj Ladkani
2019-10-24 17:45       ` Brad Bishop
2019-10-25 12:15     ` Brad Bishop
2019-10-25 12:59   ` Brad Bishop
2019-10-25 15:08     ` Matuszczak, Piotr
2019-10-25 17:31       ` Brad Bishop
2019-10-28 16:42         ` Matuszczak, Piotr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8998b51b-4e67-738e-becd-63c26ea626be@linux.intel.com \
    --to=james.feist@linux.intel.com \
    --cc=apparao.puli@linux.intel.com \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=james.mihm@intel.com \
    --cc=kunyi@google.com \
    --cc=neladk@microsoft.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=piotr.matuszczak@intel.com \
    --cc=thalerj@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.