<br><br><div class="gmail_quote">On Fri, May 11, 2012 at 3:40 PM, Loic Dachary <span dir="ltr"><<a href="mailto:loic@enovance.com" target="_blank">loic@enovance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 05/11/2012 05:55 PM, Doug Hellmann wrote:<br>
> During yesterday's meeting we discussed the API proposal at<br>
> <a href="http://wiki.openstack.org/EfficientMetering#API" target="_blank">http://wiki.openstack.org/EfficientMetering#API</a> and came up with a few<br>
> missing items and other points for discussion. We should try to work out<br>
> those details on the list before the meeting next week.<br>
><br>
> The original proposal included these API calls:<br>
><br>
> GET list components<br>
> GET list components meters (argument : name of the component)<br>
> GET list [user_id|project_id|source]<br>
> GET list of meter_type<br>
> GET list of events per [user_id|project_id|source] ( allow to specify user_id or project_id or both )<br>
> GET sum of (meter_volume, meter_duration) for meter_type and [user_id|project_id|source]<br>
><br>
> They can be broken down into three groups:<br>
><br>
> - Discover the sorts of things the server can provide:<br>
><br>
> - list the components providing metering data<br>
> - list the meters for a given component<br>
> - list the known users<br>
> - list the known projects<br>
> - list the known sources<br>
> - list the types of meters known<br>
><br>
> - Fetch raw event data, without aggregation:<br>
><br>
> - per user<br>
> - per project<br>
> - per source<br>
> - per user and project<br>
><br>
> - Produce aggregate views of the data:<br>
><br>
> - sum "volume" field for meter type over a time period<br>
> - per user<br>
> - per project<br>
> - per source<br>
> - sum "duration" field for meter type over a period of time<br>
> - per user<br>
> - per project<br>
> - per source<br>
</div></div>I updated the wiki with these three groups, it is a good starting point for discussion.<br>
<a href="http://wiki.openstack.org/EfficientMetering?action=diff&rev2=75&rev1=74" target="_blank">http://wiki.openstack.org/EfficientMetering?action=diff&rev2=75&rev1=74</a><br>
<div class="im">><br>
> We agreed that all of the queries related to metering data would need<br>
> to have parameters to set the start and end times with the start time<br>
> inclusive and the end time exclusive (i.e., start <= timestamp < end).<br>
><br>
> Callers also are likely to want to filter the raw data queries based<br>
> on the meter type, so we need to add that as an optional argument<br>
> there. The aggregate values have the meter type as a required argument<br>
> (because it does not make sense to aggregate data from separate meters<br>
> together).<br>
><br>
> There are a few other queries missing from that list. The items below<br>
> are based on the meeting notes and my own thoughts from yesterday,<br>
> please add to the list if I have left anything out (or suggest why we<br>
> should not implement something suggested here, of course):<br>
><br>
> - list discrete events that may not have a duration (instance<br>
> creation, IP allocation, etc.)<br>
> - list raw event data for a resource ("what happened with a specific<br>
> instance?")<br>
> - aggregate event data per meter type for a resource over a period of<br>
> time ("what costs are related to this instance?")<br>
> - sum volume for meter type over a time period for a specific resource<br>
> ("how much total bandwidth was used by a VIF?")<br>
> - sum duration for meter type over a time period for a specific<br>
> resource ("how long did an instance run?")<br>
> - metadata for resources (such as location of instances)<br>
> - aggregating averages in addition to sums<br>
><br>
</div>I've added this list as a note in the API chapter.<br>
<a href="http://wiki.openstack.org/EfficientMetering?action=diff&rev2=76&rev1=75" target="_blank">http://wiki.openstack.org/EfficientMetering?action=diff&rev2=76&rev1=75</a><br>
<div class="im">> Some of these items may be better handled in the consumer of this API<br>
> (the system that actually bills the user). I am curious to know how<br>
> others are handling auditing or other billing detail reporting for<br>
> users.<br>
</div>I will be in a meeting with the participants of the <a href="http://www.opencloudware.org/" target="_blank">http://www.opencloudware.org/</a> project early next week and I'll ask them. Maybe Daniel Dyer could share a practical experience with us.<br>
<div class="im"><br>
> In order to support the discrete events, we need to capture<br>
> them. Perhaps those could be implemented as additional counter<br>
> types. Thoughts?<br>
</div>Are there resources that should be billed (henced metered) if their lifespan is shorter than the polling / publishing event period ? I mean that if someone creates a VM and immediately destroys it, does it really matter. While writing this statement, I though of a way to abuse a system that does not account for discrete events like "created a VM" but only account for "this VM has run for at least X minutes" :-) One could write a software to launch short lived VM at specific times and get computing power for free.<br>
</blockquote><div><br></div><div>Exactly. We may bill the customer for the first X minutes of use for a VM just for creating it, and then do the math necessary to avoid double billing them during the first billing cycle.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do discrete event need to be separate ? Back to the example above, someone creates a VM : that does not create a record in the ceilometer storage. The VM is destroyed a few seconds later : it creates an event, as if it was polled / published to measure the uptime of the VM. The c1 meter would show the VM has been up for 15 seconds since it was created. If the c1 meter is generated from an exist event captured from <a href="http://wiki.openstack.org/SystemUsageData" target="_blank">http://wiki.openstack.org/SystemUsageData</a> that occurs every 5 minutes, the uptime will be 5 minutes more than the previous one.<br>
</blockquote><div><br></div><div>VMs may not be the best example for discussing discrete events since so much of what happens there is related to time. A better example is creating images. We may charge the user a one-time fee for uploading an image to Glance, and then charge an ongoing fee for the storage consumed. So the one-time fee is a discrete event based on creating the image.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While thinking about this use case I also had a simple idea to optimize the storage of events and added it to the wiki<br>
<a href="http://wiki.openstack.org/EfficientMetering?action=diff&rev2=77&rev1=76" target="_blank">http://wiki.openstack.org/EfficientMetering?action=diff&rev2=77&rev1=76</a><br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Loïc Dachary Chief Research Officer<br>
// eNovance labs <a href="http://labs.enovance.com" target="_blank">http://labs.enovance.com</a><br>
// ✉ <a href="mailto:loic@enovance.com">loic@enovance.com</a> ☎ <a href="tel:%2B33%201%2049%2070%2099%2082" value="+33149709982">+33 1 49 70 99 82</a><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</font></span></blockquote></div><br>