Open Stack

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.

> 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?

-- 
/*  Julien Danjou
   ╭ Free Software hacker & freelance
   ╰ http://julien.danjou.info          */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120702/e5417e63/attachment.sig>