
<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On 18 Jun 2015 at 04:44:18, gordon chung (<a href="mailto:gord@live.ca">gord@live.ca</a>) wrote:</div> <div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div></div><div><br><br>On 17/06/2015 12:57 PM, Chris Dent wrote:<span class="Apple-converted-space"> </span><br>> On Tue, 16 Jun 2015, Simon Pasquier wrote:<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>>> I'm still struggling to see how these optimizations would be implemented<span class="Apple-converted-space"> </span><br>>> since the current Gnocchi design has separate backends for indexing and<span class="Apple-converted-space"> </span><br>>> storage which means that datapoints (id + timestamp + value) and metric<span class="Apple-converted-space"> </span><br>>> metadata (tenant_id, instance_id, server group, ...) are stored into<span class="Apple-converted-space"> </span><br>>> different places. I'd be interested to hear from the Gnocchi team how<span class="Apple-converted-space"> </span><br>>> this<span class="Apple-converted-space"> </span><br>>> is going to be tackled. For instance, does it imply modifications or<span class="Apple-converted-space"> </span><br>>> extensions to the existing Gnocchi API?<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> I think there's three things to keep in mind:<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> a) The plan is to figure it out and make it work well, "production<span class="Apple-converted-space"> </span><br>> ready" even. That will require some iteration. At the moment the<span class="Apple-converted-space"> </span><br>> overlap between InfluxDB python driver maturity and someone-to-do-the-<span class="Apple-converted-space"> </span><br>> work is not great. When it is I'm sure the full variety of<span class="Apple-converted-space"> </span><br>> optimizations will be explored, with actual working code and test<span class="Apple-converted-space"> </span><br>> cases.<span class="Apple-converted-space"> </span><br><br>just curious but what bugs are we waiting on for the influxdb driver?<span class="Apple-converted-space"> </span><br>i'm hoping Paul Dix has prioritised them?<span class="Apple-converted-space"> </span><br><br>><span class="Apple-converted-space"> </span><br>> b) Gnocchi has separate _interfaces_ for indexing and storage. This<span class="Apple-converted-space"> </span><br>> is not the same as having separate _backends_[1]. If it turns out<span class="Apple-converted-space"> </span><br>> that the right way to get InfluxDB working is for it to be the<span class="Apple-converted-space"> </span><br>> same backend to the two separate interfaces then that will be<span class="Apple-converted-space"> </span><br>> okay.<span class="Apple-converted-space"> </span><br><br>i'll straddle the middle line here and say i think we need to wait for a<span class="Apple-converted-space"> </span><br>viable driver before we can start making the appropriate adjustments.<span class="Apple-converted-space"> </span><br>having said that, i think once we have the gaps resolved, i think we<span class="Apple-converted-space"> </span><br>should make all effort to conform to the rules of the db (whether it is<span class="Apple-converted-space"> </span><br>influxdb, kairosdb, opentsdb). we faced a similar issue with the<span class="Apple-converted-space"> </span><br>previous data storage design where we generically applied a design for<span class="Apple-converted-space"> </span><br>one driver across all drivers and that led to terribly inefficient<span class="Apple-converted-space"> </span><br>design everywhere.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>I'd like to emphasise that using the same backend for both data-point time-series and the identification of the resources linked to those time-series is not only the right way, it is the mandatory way. The most salient reason being that we shall not mandate other applications consuming time-series produced through Gnocchi to use anything else than the time-series backend native API. Operators who want to use InfluxDB, OpenTSDB or something else, as their time-series backend, do it for a reason. The choice of an API that best suits their needs is key to that decision. It is also a question of effectiveness. There are plenty of applications out there like Grafana that plug into those time-series out-of-the-box. I don’t think we want to force those applications to use the Gnocchi API instead.</p><p> - Patrick</p><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br><br>><span class="Apple-converted-space"> </span><br>> c) The future is unknown and the present is not made of stone. There<span class="Apple-converted-space"> </span><br>> could be modifications and extensions to the existing stuff. We<span class="Apple-converted-space"> </span><br>> don't know. Yet.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> [1] Yes the existing implementations use SQL for the indexer and<span class="Apple-converted-space"> </span><br>> various subclasses of the carbonara abstraction as two backends<span class="Apple-converted-space"> </span><br>> for the two interfaces. That's an accident of history not a design<span class="Apple-converted-space"> </span><br>> requirement.<span class="Apple-converted-space"> </span><br><br>--<span class="Apple-converted-space"> </span><br>gord<span class="Apple-converted-space"> </span><br><br><br>__________________________________________________________________________<span class="Apple-converted-space"> </span><br>OpenStack Development Mailing List (not for usage questions)<span class="Apple-converted-space"> </span><br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<span class="Apple-converted-space"> </span><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<span class="Apple-converted-space"> </span><br></div></div></span></blockquote></div></body></html>