Open Stack

On Wed, Nov 25 2015, Stéphane Albert wrote:

Hi Stéphane,

> We can't directly query gnocchi resource indexer for a specific resource
> revision. Let me explain it, if you want to search for every instances
> active for a specific timeframe you'll get a result but the revision
> will be the latest, even if it's after the timeframe you requested. If
> you add resource revision to the request you'll get an empty request if
> it doesn't match the latest version. We can't add history to the request
> as we'll have more than one response when we only need latest revision
> for the timeframe. One workaround is to first do a request to query
> every active instance and then do a query for every instance with
> history filtering on UUID and revision and limiting to one result. It's
> suboptimal as it requires many requests to get the correct information.

You really need to put actual data and request examples in your
explications, as it's really hard to follow you. Best way is to describe
what you have, what you do, what you get and what you would expect.
But I think I see what you mean, and it should be just a few API call
option to add. Best thing would be to open a bug with the details I just
mentioned.

> The other problem we are having is when requesting measures. Let me
> first tell you how CloudKitty is collecting data to set the context.
> We've got a collection period (default 3600 seconds), every period we
> query the backend for a specific timeframe (start = last collection,
> stop = last + period). If we're missing data we restart from where we
> stopped, which can be pretty far in the past.
> We're using gnocchi as ceilometer's storage and by default it's pretty
> hard to exploit data stored. If we request data too far in the past that
> is using a higher granularity than our collection period then we got an
> empty dataset from gnocchi. It's pretty ambiguous as we don't know if
> it's because there is no data, or because our timeframe is too short.
> That means we need to query for the archive policy and find what should
> be the minimum granularity for the period. In some way it's normal to no
> get data because gnocchi is unable to provide accurate data for this
> period, but at least get information that we are requesting too
> precisely. Or send us the data, since we've got the timestamp and
> the granularity, we can easily detect that the result is not accurate
> and decide what we should do.

If you specify only the timeframe and no granularity, it should send to
you all it got for this timeframe. Isn't that good enough for you?

-- 
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/20151125/635e493d/attachment.pgp>