[openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases

gordon chung gord at live.ca
Thu Jun 18 02:39:02 UTC 2015

On 17/06/2015 12:57 PM, Chris Dent wrote:
> On Tue, 16 Jun 2015, Simon Pasquier wrote:
>> I'm still struggling to see how these optimizations would be implemented
>> since the current Gnocchi design has separate backends for indexing and
>> storage which means that datapoints (id + timestamp + value) and metric
>> metadata (tenant_id, instance_id, server group, ...) are stored into
>> different places. I'd be interested to hear from the Gnocchi team how 
>> this
>> is going to be tackled. For instance, does it imply modifications or
>> extensions to the existing Gnocchi API?
> I think there's three things to keep in mind:
> a) The plan is to figure it out and make it work well, "production
>    ready" even. That will require some iteration. At the moment the
>    overlap between InfluxDB python driver maturity and someone-to-do-the-
>    work is not great. When it is I'm sure the full variety of
>    optimizations will be explored, with actual working code and test
>    cases.

just curious but what bugs are we waiting on for the influxdb driver? 
i'm hoping Paul Dix has prioritised them?

> b) Gnocchi has separate _interfaces_ for indexing and storage. This
>    is not the same as having separate _backends_[1]. If it turns out
>    that the right way to get InfluxDB working is for it to be the
>    same backend to the two separate interfaces then that will be
>    okay.

i'll straddle the middle line here and say i think we need to wait for a 
viable driver before we can start making the appropriate adjustments. 
having said that, i think once we have the gaps resolved, i think we 
should make all effort to conform to the rules of the db (whether it is 
influxdb, kairosdb, opentsdb). we faced a similar issue with the 
previous data storage design where we generically applied a design for 
one driver across all drivers and that led to terribly inefficient 
design everywhere.

> c) The future is unknown and the present is not made of stone. There
>    could be modifications and extensions to the existing stuff. We
>    don't know. Yet.
> [1] Yes the existing implementations use SQL for the indexer and
> various subclasses of the carbonara abstraction as two backends
> for the two interfaces. That's an accident of history not a design
> requirement.


More information about the OpenStack-dev mailing list