Open Stack

On Mon, Jul 2, 2012 at 5:54 PM, Julien Danjou <julien at danjou.info> wrote:

> On Mon, Jul 02 2012, Doug Hellmann wrote:
>
> > No, there are cases where the metadata will affect the rate. For
> instance,
> > it costs a different amount to have an instance in each of Amazon's
> > availability zones (data centers). The counter would still say that the
> > instance has been running for a certain amount of time, but the *rate*
> for
> > charging for that time would depend on where it is. A representative from
> > HP requested the same thing in ceilometer, and we may use it at
> DreamHost,
> > too, eventually.
>
> I totally agree with you, Doug. I'm just saying that's it's not *only* a
> metadata. The zone must be some kind of a meter, even if it's not
> numeric. It should be a meter with a type that causes the resource (here
> the instance) to be billed differently (and therefore to generate
> multiple "objects" when returning resource usage metering).
>

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?

Clearly the term meter is probably not the good one, maybe we should
> split this, but to me it must be extracted from metadata to become
> something more. Something we can rely on to take the decision that "this
> is something worst splitting the metered resource in different parts
> because the billing must change" (zone, RAM, flavor, volume size…).
>
> Speaking of volume size, if you take the example of a storage volume,
> you likely to have the same issue. You may not charge the same thing if
> your volume total size is 1 GB or 10 GB, and if it has been resize you
> want (not sure it's possible, but one day) to know when precisely.
> Whereas size used is likely to be just a generic absolute meter.
>

A better example would be charging different rates for SSD vs. traditional
storage.

> We probably have time to fix it before the release. On the other hand, it
> > seems much more important to use work on writing data collectors (new
> > pollsters, adding notifications to other projects, etc.). I don't think
> we
> > can do both things.
>
> Sure. Anyway, we both know that's a do-ocracy. :-)
>

Darn, I was hoping you'd say you'd do it. ;-)

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120702/18f06acd/attachment.html>