cumulative meters that reset might present incorrect values

[gordon chung]

09:37 < gordc> jd__: for the gnocchi work, it doesn't solve the issue where derived samples (ie. cpu_util) get reset
               right?
09:39 < jd__> gordc: depends on what you want to do?
09:40 < jd__> obviously it's the day you want to release you realize you don't have the right permissions
09:42 < gordc> jd__: i'm just thinking of when we use cputime to compute util... the cputime we poll will still get
               reset so our util value will still be wrong the first sample after reset
09:43 < gordc> jd__: http://lists.openstack.org/pipermail/openstack-dev/2015-April/061631.html
09:44 < jd__> gordc: again it depends on at you do and what kind of aggregation you use :)
09:44 < gordc> sileht: there is this bug https://bugs.launchpad.net/ceilometer/+bug/1434322
09:45 < jd__> gordc: because I think for things like average() it does not make sense anyway so yeah it's broken but
              it's not a big deal
09:47 < gordc> jd__: ah i see... so it'll really only be an issue if you have super granular policy, or when you are
               rolling stuff up (in certain cases)
09:48 < jd__> gordc: yeah you can just use the last() aggregation mechanism to have the latest value for a period of
              X minutes of time and then handle the reset case yourself to do your computation
09:48 < jd__> gordc: the only thing we *might* be missing is the information that this is a metric that is measuring
              something that can reset
09:48 < jd__> gordc: this has to be in the client intelligence for now