Open Stack

On Thu, Nov 26, 2015 at 05:31:38PM +0100, Julien Danjou wrote:
> On Thu, Nov 26 2015, Stéphane Albert wrote:
> 
> > I'll open a bug with a full history dump, sometime it's due to the host
> > changing (flapping) from name to hash, this might be due to
> > ceilometer.
> 
> This would be a Ceilometer (or above) bug indeed. I think I saw
> something recently. It's possible the host differs between polling and
> notifications; feel free to also open a bug on the Ceilometer side.
I'll see if there's a bug declared in ceilometer's bug tracker and if
not report a new one.
> 
> >> > Search for active instances during a timeframe
> >> > ==============================================
> >> 
> >> […]
> >> 
> >> > Here the revision is outside of the requested timeframe.
> >> 
> >> I don't get that comment. You didn't ask for any specific revision, you
> >> asked for a start/end timestamps. So that looks correct to me. You get
> >> the instances that was active between 10:33 and 17:33.
> > I didn't ask for a specific revision because I can't ;)
> 
> Why can't you? You can request revisions based on their timeframes.
By "I can't" I meant I can't without asking for history. I just want to
have the same result as the standard query (the latest revision) but
with a maximum revision timestamp.
> Or is it because the revision date is based no the upload timestamp
> rather than the actual date of the revision?
> 
> This is something we could fix in the API and Ceilometer I imagine,
> giving the ability to provide a timestamp for the change.
> 
> > If there is more than one revision, then I'll get multiple revisions for
> > a resource. This imply that you request all the revisions and then
> > filter them client side. It's not the most efficient way to proceed as
> > it could be directly done in the DB query.
> 
> But but… there might be multiple revision between two timeframe. If you
> want to rate an instance that was up during 10:33 and 17:33, and that
> resource has been e.g. resized 3 times at 12:00, 13:00 and 15:00, you'll
> get 3 revisions from Gnocchi. Isn't that what you want?
Yes and no... In CloudKitty the collection period is our epsilon. So we
won't process multiple values for it. That's the way CloudKitty is
working at the moment, it might change in the future. We get the latest
metas and most of the time get max value from the aggregated measures
(vcpus, mem, disk, etc). It's just that at the moment ceilometer/gnocchi
is returning way too much revisions for a timeframe (and they don't have
relevant data most of the time). If we query all active instances for a
tenant we can quickly get huge load of data.

We'll have support for ceilometer events soon, so we'll start doing diff
on gnocchi resources to detect changes and apply rate on these. But at
the moment it's out of our scope.