<br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 1:19 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 Fri, Jun 29 2012, Doug Hellmann wrote:<br>
<br>
</div><div class="im">> We do have counters for RAM and CPU separate from instance. But the rate at<br>
> which the provider bills for those things may vary based on metadata. My<br>
> example may be bad because it uses 2 values we're measuring, one of which<br>
> also shows up in the metadata for another. As a different example, take the<br>
> instance display name. The display name is under the control of the user<br>
> and is extremely unlikely to reflect a change in the billing rate. However,<br>
> changing the display name changes the metadata for the instance. A naive<br>
> implementation of the processing loop would pick that up and generate<br>
> multiple documents even though there is no need to do so.<br>
<br>
</div>Yep, but the display name is not a counter. Memory is a counter. An<br>
instance is made of several counter. We need to split metered objects<br>
based on their "absolute" counter changing (memory, number of core…),<br>
not based on random metadata, i.e. a resource have several meters.<br></blockquote><div><br></div><div>I don't think I've made the problem clear.</div><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So what was considered as metadata (like memory) so far should changed<br>
to become a meter of an resource (like an instance) and have for this<br>
one a special type (not sure about the type name to use).<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We may need to refine our model to be a bit more hierarhical like:<br>
<br>
resource --> counter #1 of type 'relative'<br>
      |  `-> counter #2 of type 'absolute'<br>
      `----> counter #3 of type 'if-i-change-you-need-to-split-the-resource-in-several-stuff'<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
     etc…<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
           Julien<br>
</font></span></blockquote></div><br>