<br><br><div class="gmail_quote">On Mon, Jul 2, 2012 at 4:58 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>Hi Doug,<br>
<br>
Sorry for the late reply.<br>
<div class="im"><br>
> I don't think I've made the problem clear.<br>
><br>
> I'm not talking about wanting to calculate the different usage for CPU,<br>
> RAM, etc. The different counters are calculated separately, so we can keep<br>
> the amounts for CPU and RAM completely separate, and the API allows the<br>
> outside user to ask for the amounts for each counter for a resource (or<br>
> globally for a user/project). The problem is in deciding how the metadata<br>
> associated with a meter event might cause the provider to change the rate<br>
> they want to charge for that usage.<br>
<br>
</div>It's not metadata of a counter that cause the provider to change the<br>
rate. It's a meter of a resource that can do that.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> That only solves part of the problem, though. As a provider I may want to<br>
> charge different flat rates for the amount of RAM being used. For example,<br>
> 1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the size<br>
> of the VM changes, we need to produce multiple totals (the length of time<br>
> that the VM had 1024 MB RAM and then the length of time it had 4096 MB RAM).<br>
<br>
</div>Yeah, like I said, for the meter 'RAM' of resource 'instance' you can't<br>
request a total amount used, because the type of this meter (I don't<br>
know how to call it, it's the kind I named<br>
if-i-change-you-need-to-split-the-resource-in-several-stuff in my latest<br>
email) don't have this semantic.<br>
<div class="im"><br>
> I might also want to change the rate I bill when a VM is migrated between<br>
> hosts or availability zones (I think we said migration caused a new<br>
> instance to be created, but bear with me). The availability zone for an<br>
> instance is clearly metadata and not something we can track via a counter.<br>
<br>
</div>Again, that's also a meter that has the same type of 'RAM' for a<br>
resource 'instance'.<br>
<div class="im"><br>
> That's an interesting idea, and it might solve the problem. At this point<br>
> in the Folsom schedule though, I would much rather implement a pared down<br>
> API that handles the simple cases but makes the caller do a bit more data<br>
> manipulation for complex cases, in favor of focusing on counting more<br>
> things than we do now. Is that a reasonable approach?<br>
<br>
</div>Problem is that we might break the API a bit with this. This would not<br>
be the first time an OpenStack API is broken, but if we can avoid it,<br>
it'd be better. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am not sure you can really bill anything if you're not able to handle<br>
a simple thing such a VM resize. So currently, it seems that the API is<br>
not designed correctly to handle such a case, and since it's not yet<br>
implemented, maybe it's still time to fix it?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Doug</div><div><br></div></div>