aggregate new measures fairly

[gordon chung]

list_metric_with_measures_to_process lists all the metrics available to be processed. it grabs the first x items from the resultset. the order of resultset is not controlled right now and is dictated by backend. it's very common if you don't have a fast enough processing rate or large enough amount of workers that certain metrics will never be processed as it will always get pushed back in line by other metrics. this for sure happens in ceph.

it'd be nice if list_metric_with_measures_to_process returned back based on earliest time unprocessed measures were add. that way, we could fairly process all measures without having to resort to high processing rate

work around is to always use 'refresh=True' on query so you guarantee latest.

i think this is a bug.. and a complicated bug... but possibly low priority since there's workaround.

[gordon chung (chungg)]

related http://lists.openstack.org/pipermail/openstack-dev/2016-November/107284.html

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/441389
Committed: https://git.openstack.org/cgit/openstack/gnocchi/commit/?id=9889bd04f5ae9949c739ab656771aa5b8c1bab95
Submitter: Jenkins
Branch: master

commit 9889bd04f5ae9949c739ab656771aa5b8c1bab95
Author: gord chung <email address hidden>
Date: Fri Mar 3 19:31:20 2017 +0000

    push incoming into different sacks

    having everything in one giant folder/bucket/container/object is bad
    because:
    - does not allow for good distribution of backend driver.
    - makes it hella hard to cleanly split work across multiple metricd
    - starves metrics from being processed.

    we used "sacks" to avoid naming same as driver paradigms.

    driver implementation will be done individually so this does nothing but
    pretend to lock multiple buckets when it's actually just one.

    Related-Bug: #1629420
    Related-Bug: #1623263
    Related-Bug: #1620674
    Change-Id: Icc32d918fe55416385122470c47d60ddbb30dd34