Open Stack

On Fri, Sep 16 2016, Sam Morrison wrote:

Hi Sam,

> Been working a bit on this and have a patch based on master that is
> working at:
>
> https://github.com/NeCTAR-RC/gnocchi/tree/influxdb-driver

Great!

> I could push it up to gerrit but I think something will need to change
> for it to run the influxdb tests?

You can use pifpaf like we do for the indexer, InfluxDB is supported.
That should make it possible to run the unit tests in the gate right
away.

As for the functional tests, you can set up support via devstack and
we wouldhad a job in infra.

> It should act more like the carbonara drivers now as opposed to the
> old influx driver. It will do downsampling and retention based on the
> archive policies.

That's great, and I imagine it'd be faster than doing it on the fly like
previously.

> Currently it is failing one test [1] and that is to do with retention. 
> This is because influxDB does retention based on the current time, e.g. a 1 day retention policy will be from the current time. 
> The tests assume that the retention period is based on the data stored and so it will keep 1 day of data no matter how old that data is.

lol, yeah the test assume it's a database that does not block you to
insert things as you want. I feel like that being a bad and funny design
decision (Whisper has the same defect).

> I also had to disable retention policies in influx while running the tests as
> when I backfill data influx is too smart and won’t backfill data that wouldn’t
> meet the retention policy.

I imagine that's because some of our tests are using date in year e.g.
2014? :)

> One way to fix all this would be to change all the test times to be
> relative from now but then there could be other race conditions etc. I
> think.

Completely, imagine if the test takes 1 month to run, it would fail
anyway. ;-) It's completely hypothetical and unrealaistic of course, but
in principle I think it's better if we can keep things the way they are.

> I’m still not 100% happy with the code, particularly around how the
> continuous queries are created based on the archive policies.
>
> We are using this code in preprod and so far all is going well. 

Great. Do you have performance numbers, scalability, or things that are
different/better/worse than using Carbonara based drivers?

Cheers,
-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160916/0c64ffbc/attachment.pgp>