<font size=2 face="sans-serif">Hi Eoghan,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the note below. However,
one thing the overview below does not cover is why InfluxDB
(</font><a href=http://influxdb.com/><font size=2 face="sans-serif">http://influxdb.com/</font></a><font size=2 face="sans-serif">)
is not being leveraged. Many folks feel that this technology is a
viable solution for the problem space discussed below.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
<br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet: btopol@us.ibm.com<br>
Assistant: Kendra Witherspoon (919) 254-0680</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Eoghan Glynn <eglynn@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">08/06/2014 11:17 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[openstack-dev]
[tc][ceilometer] Some background on the gnocchi project</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2><br>
Folks,<br>
<br>
It's come to our attention that some key individuals are not<br>
fully up-to-date on gnocchi activities, so it being a good and<br>
healthy thing to ensure we're as communicative as possible about<br>
our roadmap, I've provided a high-level overview here of our<br>
thinking. This is intended as a precursor to further discussion<br>
with the TC.<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
<br>
What gnocchi is:<br>
===============<br>
<br>
Gnocchi is a separate, but related, project spun up on stackforge<br>
by Julien Danjou, with the objective of providing efficient<br>
storage and retrieval of timeseries-oriented data and resource<br>
representations.<br>
<br>
The goal is to experiment with a potential approach to addressing<br>
an architectural misstep made in the very earliest days of<br>
ceilometer, specifically the decision to store snapshots of some<br>
resource metadata alongside each metric datapoint. The core idea<br>
is to move to storing datapoints shorn of metadata, and instead<br>
allow the resource-state timeline to be reconstructed more cheaply<br>
from much less frequently occurring events (e.g. instance resizes<br>
or migrations).<br>
<br>
<br>
What gnocchi isn't:<br>
==================<br>
<br>
Gnocchi is not a large-scale under-the-radar rewrite of a core<br>
OpenStack component along the lines of keystone-lite.<br>
<br>
The change is concentrated on the final data-storage phase of<br>
the ceilometer pipeline, so will have little initial impact on the<br>
data-acquiring agents, or on transformation phase.<br>
<br>
We've been totally open at the Atlanta summit and other forums<br>
about this approach being a multi-cycle effort.<br>
<br>
<br>
Why we decided to do it this way:<br>
================================<br>
<br>
The intent behind spinning up a separate project on stackforge<br>
was to allow the work progress at arms-length from ceilometer,<br>
allowing normalcy to be maintained on the core project and a<br>
rapid rate of innovation on gnocchi.<br>
<br>
Note that that the developers primarily contributing to gnocchi<br>
represent a cross-section of the core team, and there's a regular<br>
feedback loop in the form of a recurring agenda item at the<br>
weekly team meeting to avoid the effort becoming silo'd.<br>
<br>
<br>
But isn't re-architecting frowned upon?<br>
======================================<br>
<br>
Well, the architecture of other OpenStack projects have also<br>
under-gone change as the community understanding of the<br>
implications of prior design decisions has evolved.<br>
<br>
Take for example the move towards nova no-db-compute & the<br>
unified-object-model in order to address issues in the nova<br>
architecture that made progress towards rolling upgrades<br>
unneccessarily difficult.<br>
<br>
The point, in my understanding, is not to avoid doing the<br>
course-correction where it's deemed necessary. Rather, the<br>
principle is more that these corrections happen in an open<br>
and planned way.<br>
<br>
<br>
The path forward:<br>
================<br>
<br>
A subset of the ceilometer community will continue to work on<br>
gnocchi in parallel with the ceilometer core over the remainder<br>
of the Juno cycle and into the Kilo timeframe. The goal is to<br>
have an initial implementation of gnocchi ready for tech preview<br>
by the end of Juno, and to have the integration/migration/<br>
co-existence questions addressed in Kilo.<br>
<br>
Moving the ceilometer core to using gnocchi will be contingent<br>
on it demonstrating the required performance characteristics and<br>
providing the semantics needed to support a v3 ceilometer API<br>
that's fit-for-purpose.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>