Open Stack

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.

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.

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.
-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent