Open Stack

On Fri, Jun 29, 2012 at 1:19 PM, Julien Danjou <julien at danjou.info> wrote:

> On Fri, Jun 29 2012, Doug Hellmann wrote:
>
> > We do have counters for RAM and CPU separate from instance. But the rate
> at
> > which the provider bills for those things may vary based on metadata. My
> > example may be bad because it uses 2 values we're measuring, one of which
> > also shows up in the metadata for another. As a different example, take
> the
> > instance display name. The display name is under the control of the user
> > and is extremely unlikely to reflect a change in the billing rate.
> However,
> > changing the display name changes the metadata for the instance. A naive
> > implementation of the processing loop would pick that up and generate
> > multiple documents even though there is no need to do so.
>
> Yep, but the display name is not a counter. Memory is a counter. An
> instance is made of several counter. We need to split metered objects
> based on their "absolute" counter changing (memory, number of core…),
> not based on random metadata, i.e. a resource have several meters.
>

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.


> So what was considered as metadata (like memory) so far should changed
> to become a meter of an resource (like an instance) and have for this
> one a special type (not sure about the type name to use).
>

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).

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.


>
> We may need to refine our model to be a bit more hierarhical like:
>
> resource --> counter #1 of type 'relative'
>      |  `-> counter #2 of type 'absolute'
>      `----> counter #3 of type
> 'if-i-change-you-need-to-split-the-resource-in-several-stuff'
>

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?


>
>     etc…
>
> --
>           Julien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120629/bd1e2ee5/attachment.html>