Open Stack

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

> On Fri, Jun 29 2012, Doug Hellmann wrote:
>
> Hi Doug,
>
> Sorry for the late reply.
>
> > I don't think I've made the problem clear.
> >
> > I'm not talking about wanting to calculate the different usage for CPU,
> > RAM, etc. The different counters are calculated separately, so we can
> keep
> > the amounts for CPU and RAM completely separate, and the API allows the
> > outside user to ask for the amounts for each counter for a resource (or
> > globally for a user/project). The problem is in deciding how the metadata
> > associated with a meter event might cause the provider to change the rate
> > they want to charge for that usage.
>
> It's not metadata of a counter that cause the provider to change the
> rate. It's a meter of a resource that can do that.
>

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.

> That only solves part of the problem, though. As a provider I may want to
> > charge different flat rates for the amount of RAM being used. For
> example,
> > 1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the
> size
> > of the VM changes, we need to produce multiple totals (the length of time
> > that the VM had 1024 MB RAM and then the length of time it had 4096 MB
> RAM).
>
> Yeah, like I said, for the meter 'RAM' of resource 'instance' you can't
> request a total amount used, because the type of this meter (I don't
> know how to call it, it's the kind I named
> if-i-change-you-need-to-split-the-resource-in-several-stuff in my latest
> email) don't have this semantic.
>
> > I might also want to change the rate I bill when a VM is migrated between
> > hosts or availability zones (I think we said migration caused a new
> > instance to be created, but bear with me). The availability zone for an
> > instance is clearly metadata and not something we can track via a
> counter.
>
> Again, that's also a meter that has the same type of 'RAM' for a
> resource 'instance'.
>
> > That's an interesting idea, and it might solve the problem. At this point
> > in the Folsom schedule though, I would much rather implement a pared down
> > API that handles the simple cases but makes the caller do a bit more data
> > manipulation for complex cases, in favor of focusing on counting more
> > things than we do now. Is that a reasonable approach?
>
> Problem is that we might break the API a bit with this. This would not
> be the first time an OpenStack API is broken, but if we can avoid it,
> it'd be better.


> I am not sure you can really bill anything if you're not able to handle
> a simple thing such a VM resize. So currently, it seems that the API is
> not designed correctly to handle such a case, and since it's not yet
> implemented, maybe it's still time to fix it?
>

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.

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