[openstack-dev] [ceilometer] The reset on the cumulative counter

Doug Hellmann doug.hellmann at dreamhost.com
Mon Nov 26 15:54:07 UTC 2012


On Mon, Nov 26, 2012 at 8:53 AM, Julien Danjou <julien at danjou.info> wrote:

> On Mon, Nov 26 2012, Jiang, Yunhong wrote:
>
> Hi,
>
> […]
>
> >       There are several method on this, like JD's MAX()- FIRST(), or
> > asalkeld's idea of store the offset. Both try to detect if there is reset
> > happen by checking if there is counter reverse. (again, Eglynn, please
> > correct me if I'm wrong).
>
> I've indeed already express my point of view of solving this issue, but
> I can do it here again.:)
>
> I'm against trying to do anything fancy on calculation in pollsters, and
> want always see raw data sent to the collector. One promise of
> Ceilometer has always been to do no aggregation of any kind.
>
> The "final value" computing problem is a probably easily solved with the
> good algorithm in the API, and more specifically via the storage backend
> if it's capable of doing it (at least SQL is, and I'm pretty sure
> MongoDB would be).
>

I'm a little concerned about how either implementation would actually
perform when calculating the values on an API call. I've thought about
doing it when the counter data is reported, but I'm not sure there's an
atomic way to do the update cleanly.

If we do decide to handle the calculation during the API query, we need to
ensure all backends can support it. Did we have a SQL solution that wasn't
tied to the underlying database (I remember a Postgresql solution using
window functions, but don't know about one for MySQL)?


>
> […]
>
> >       My proposal is to fix this issue from nova side as it's nova bug.
> > Per my understanding, the reason is different view of openstack/libvirt.
> For
> > openstack, the instance is a logic object, thus still exist after
> > suspend/resumt, while for libvirt, it's a real object, qemu process,
> which
> > does not exist after suspend/resume. Nova should translate libvirt's
> view to
> > openstack's view. And this issue happens to other functionality, like
> nova's
> > get_diagnostic(). But I agree with Eglynn that there are several
> > implementation difficulties to fix it from nova side.
>
> Just to be clear, that's a totally different issue. The fact that you
> want to fix this in Nova is understandable, but you're not unfortunately
> not going to be able to fix it for every pollsters people will write in
> the future.
>
> So both problems have to be addressed:
> 1. how to deal with resetable counters
> 2. how to prevent counters to be reset
>
> And I agree with you that 2. is more a Nova issue than a Ceilometer one,
> since we want that value to be provided by Nova at some point and not by
> libvirt directly IIUC, which is a good idea.
>
> --
> Julien Danjou
> # Free Software hacker & freelance
> # http://julien.danjou.info
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121126/a41107f4/attachment.html>


More information about the OpenStack-dev mailing list