RFC for Telemetry data collection

[Brad Bishop]

> On Sep 7, 2017, at 11:29 PM, Deepak Kodihalli <dkodihal at linux.vnet.ibm.com> wrote:
> 
> On 08/09/17 6:46 am, Brad Bishop wrote:
>> Hi Tom
>> I don’t really disagree with anything you wrote…I’m just throwing out some additional thoughts.
>> I would propose that we:
>> 1 - Add support to the REST server to subscribe to DBus signals, and simply forward the signal content in JSON format out over a websocket.  This allows an external user to get any async notification that any code running on the BMC can get.  I have a lot of questions on specifics here but I’ll save those for later, in case this doesn’t work out.
> 

You only quoted #1 here.  I’m highlighting that because terms like notification, event, and telemetry are being used a little loosely and we are not all on the same page.

I think we need to accommodate both async and sync/historical modes where async is just streamed out of the BMC, and sync, out of necessity have dbus objects created.  Hence my proposal for two applications, one for each mode.

Really trying to drive my point here - to put the above another way - in terms of how I have described these two modes, Toms thread (this thread) would be tackling async mode and your note thread (https://lists.ozlabs.org/pipermail/openbmc/2017-September/009065.html) covering sync/historical mode.

> Brad, that sounds fine to me in terms of how a notification can be sent, although Tom's proposal also talked about describing in yaml, how frequently to read something off of a, say a d-bus object representing a sensor.

My initial thinking is that neither of the proposed applications would ever be doing sync reads to a dbus object.  Rather, they just passively sit there and consume signals.  If need be they could discard them (see rate-limiting below).


> If I understood correctly, are you saying instead of doing this every X hours or seconds, we send out a notification whenever a PropertyChanged d-bus signal is caught?

Yes and no.  I am proposing we consume signals rather than perform reads but I still think we need:

1 - An API to configure async mode (what to subscribe to, maybe some kind of rate limiting).  I’m not sure if this would be a DBus API or just a REST thing.

2 - A robust YAML syntax that instructs application #2 (sync mode) to do the same things as #1 (what to subscribe to, rate limiting when creating historical snapshot objects).


> And let an off-BMC application bother about averages, min/max?
> 
> 
> Regards,
> Deepak