<br><br><div class="gmail_quote">On Mon, Jul 2, 2012 at 5:54 PM, 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">
<div class="im">On Mon, Jul 02 2012, Doug Hellmann wrote:<br>
<br>
> No, there are cases where the metadata will affect the rate. For instance,<br>
> it costs a different amount to have an instance in each of Amazon's<br>
> availability zones (data centers). The counter would still say that the<br>
> instance has been running for a certain amount of time, but the *rate* for<br>
> charging for that time would depend on where it is. A representative from<br>
> HP requested the same thing in ceilometer, and we may use it at DreamHost,<br>
> too, eventually.<br>
<br>
</div>I totally agree with you, Doug. I'm just saying that's it's not *only* a<br>
metadata. The zone must be some kind of a meter, even if it's not<br>
numeric. It should be a meter with a type that causes the resource (here<br>
the instance) to be billed differently (and therefore to generate<br>
multiple "objects" when returning resource usage metering).<br></blockquote><div><br></div><div>OK, I think I understand what you're saying, but I don't see how splitting the metadata out to a separate meter helps. In the specific example I gave, the rate for one item depends on the time for another value. Splitting them out and measuring them separately makes it even harder to aggregate them, doesn't it?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Clearly the term meter is probably not the good one, maybe we should<br>
split this, but to me it must be extracted from metadata to become<br>
something more. Something we can rely on to take the decision that "this<br>
is something worst splitting the metered resource in different parts<br>
because the billing must change" (zone, RAM, flavor, volume size…).<br>
<br>
Speaking of volume size, if you take the example of a storage volume,<br>
you likely to have the same issue. You may not charge the same thing if<br>
your volume total size is 1 GB or 10 GB, and if it has been resize you<br>
want (not sure it's possible, but one day) to know when precisely.<br>
Whereas size used is likely to be just a generic absolute meter.<br></blockquote><div><br></div><div>A better example would be charging different rates for SSD vs. traditional storage.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> We probably have time to fix it before the release. On the other hand, it<br>
> seems much more important to use work on writing data collectors (new<br>
> pollsters, adding notifications to other projects, etc.). I don't think we<br>
> can do both things.<br>
<br>
</div>Sure. Anyway, we both know that's a do-ocracy. :-)<br></blockquote><div><br></div><div>Darn, I was hoping you'd say you'd do it. ;-)</div><div><br>Doug</div><div><br></div></div>