On 01/09/2015 12:10 PM, Julien Danjou wrote:
On Tue, Sep 01 2015, gord chung wrote:
but if it's not actually cumulative in Ceilometer (pre-storage), should we
really be tagging it as such?
We only have 3 meters type, and the cumulative definition I wrote
somewhere back in 2012 states that
On 31/08/2015 3:36 PM, Julien Danjou wrote:
On Mon, Aug 31 2015, gord chung wrote:
i'm not sure Gnocchi is where we should be fixing this as it really only
(potentially) fixes it for Gnocchi and not for any of the other ways Ceilometer
data can be consumed.
The ideal way is to send the data
On Tue, Sep 01 2015, gord chung wrote:
> but if it's not actually cumulative in Ceilometer (pre-storage), should we
> really be tagging it as such?
We only have 3 meters type, and the cumulative definition I wrote
somewhere back in 2012 states that it can reset to 0. Sorry. :-)
> so i was
hi
i'm reaching out for help understanding meter values across hypervisors.
for context, we have an open bug in Ceilometer where the value used to
capture cputime of an instance is being reset whenever the instance is
restarted or shutdown[1]. this seems to be the expected behaviour for
On Mon, Aug 31 2015, gord chung wrote:
> for context, we have an open bug in Ceilometer where the value used to capture
> cputime of an instance is being reset whenever the instance is restarted or
> shutdown[1]. this seems to be the expected behaviour for libvirt driver[2] but
> it conflicts
On 31/08/2015 1:06 PM, Julien Danjou wrote:
On Mon, Aug 31 2015, gord chung wrote:
for context, we have an open bug in Ceilometer where the value used to capture
cputime of an instance is being reset whenever the instance is restarted or
shutdown[1]. this seems to be the expected behaviour
On Mon, Aug 31 2015, gord chung wrote:
> i think that's the reason the bug is raised... that's not what cumulative
> means. by definition it should increase over each successive value.
Well in a perfect world it would not, but with computers and numbers
coded in bit it does.
The bug about that
