<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 8:53 AM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Nov 26 2012, Jiang, Yunhong wrote:<br>
<br>
Hi,<br>
<br>
[…]<br>
<div class="im"><br>
> There are several method on this, like JD's MAX()- FIRST(), or<br>
> asalkeld's idea of store the offset. Both try to detect if there is reset<br>
> happen by checking if there is counter reverse. (again, Eglynn, please<br>
> correct me if I'm wrong).<br>
<br>
</div>I've indeed already express my point of view of solving this issue, but<br>
I can do it here again.:)<br>
<br>
I'm against trying to do anything fancy on calculation in pollsters, and<br>
want always see raw data sent to the collector. One promise of<br>
Ceilometer has always been to do no aggregation of any kind.<br>
<br>
The "final value" computing problem is a probably easily solved with the<br>
good algorithm in the API, and more specifically via the storage backend<br>
if it's capable of doing it (at least SQL is, and I'm pretty sure<br>
MongoDB would be).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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)?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[…]<br>
<div class="im"><br>
> My proposal is to fix this issue from nova side as it's nova bug.<br>
> Per my understanding, the reason is different view of openstack/libvirt. For<br>
> openstack, the instance is a logic object, thus still exist after<br>
> suspend/resumt, while for libvirt, it's a real object, qemu process, which<br>
> does not exist after suspend/resume. Nova should translate libvirt's view to<br>
> openstack's view. And this issue happens to other functionality, like nova's<br>
> get_diagnostic(). But I agree with Eglynn that there are several<br>
> implementation difficulties to fix it from nova side.<br>
<br>
</div>Just to be clear, that's a totally different issue. The fact that you<br>
want to fix this in Nova is understandable, but you're not unfortunately<br>
not going to be able to fix it for every pollsters people will write in<br>
the future.<br>
<br>
So both problems have to be addressed:<br>
1. how to deal with resetable counters<br>
2. how to prevent counters to be reset<br>
<br>
And I agree with you that 2. is more a Nova issue than a Ceilometer one,<br>
since we want that value to be provided by Nova at some point and not by<br>
libvirt directly IIUC, which is a good idea.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
# Free Software hacker & freelance<br>
# <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>