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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
