<div><div>During yesterday's meeting we discussed the API proposal at</div><div><a href="http://wiki.openstack.org/EfficientMetering#API">http://wiki.openstack.org/EfficientMetering#API</a> and came up with a few</div>
<div>missing items and other points for discussion. We should try to work out</div><div>those details on the list before the meeting next week.</div><div><br></div><div>The original proposal included these API calls:</div>
<div><br></div><div>GET list components</div><div>GET list components meters (argument : name of the component)</div><div>GET list [user_id|project_id|source]</div><div>GET list of meter_type</div><div>GET list of events per [user_id|project_id|source] ( allow to specify user_id or project_id or both )</div>
<div>GET sum of (meter_volume, meter_duration) for meter_type and [user_id|project_id|source]</div><div><br></div><div>They can be broken down into three groups:</div><div><br></div><div>- Discover the sorts of things the server can provide:</div>
<div><br></div><div>  - list the components providing metering data</div><div>  - list the meters for a given component</div><div>  - list the known users</div><div>  - list the known projects</div><div>  - list the known sources</div>
<div>  - list the types of meters known</div><div><br></div><div>- Fetch raw event data, without aggregation:</div><div><br></div><div>  - per user</div><div>  - per project</div><div>  - per source</div><div>  - per user and project</div>
<div><br></div><div>- Produce aggregate views of the data:</div><div><br></div><div>  - sum "volume" field for meter type over a time period</div><div>    - per user</div><div>    - per project</div><div>    - per source</div>
<div>  - sum "duration" field for meter type over a period of time</div><div>    - per user</div><div>    - per project</div><div>    - per source</div><div><br></div><div>We agreed that all of the queries related to metering data would need</div>
<div>to have parameters to set the start and end times with the start time</div><div>inclusive and the end time exclusive (i.e., start <= timestamp < end).</div><div><br></div><div>Callers also are likely to want to filter the raw data queries based</div>
<div>on the meter type, so we need to add that as an optional argument</div><div>there. The aggregate values have the meter type as a required argument</div><div>(because it does not make sense to aggregate data from separate meters</div>
<div>together).</div><div><br></div><div>There are a few other queries missing from that list. The items below</div><div>are based on the meeting notes and my own thoughts from yesterday,</div><div>please add to the list if I have left anything out (or suggest why we</div>
<div>should not implement something suggested here, of course):</div><div><br></div><div>- list discrete events that may not have a duration (instance</div><div>  creation, IP allocation, etc.)</div><div>- list raw event data for a resource ("what happened with a specific</div>
<div>  instance?")</div><div>- aggregate event data per meter type for a resource over a period of</div><div>  time ("what costs are related to this instance?")</div><div>- sum volume for meter type over a time period for a specific resource</div>
<div>  ("how much total bandwidth was used by a VIF?")</div><div>- sum duration for meter type over a time period for a specific</div><div>  resource ("how long did an instance run?")</div><div>- metadata for resources (such as location of instances)</div>
<div>- aggregating averages in addition to sums</div><div><br></div><div>Some of these items may be better handled in the consumer of this API</div><div>(the system that actually bills the user). I am curious to know how</div>
<div>others are handling auditing or other billing detail reporting for</div><div>users.</div><div><br></div><div>In order to support the discrete events, we need to capture</div><div>them. Perhaps those could be implemented as additional counter</div>
<div>types. Thoughts?</div><div><br></div><div>In order to provide the metadata we need to capture it. Some metadata</div><div>may change (location), so we need to support updates.</div><div><br></div><div>- The interesting metadata for a resource may depend on the type of</div>
<div>  resource. Do we need separate "tables" for that or can we normalize</div><div>  somehow?</div><div>- How do we map a resource to the correct version of its metadata at</div><div>  any given time? Timestamps seem brittle.</div>
<div>- Do we need to reflect the metadata in the aggregation API?</div><div><br></div><div>We also discussed extensions, but we should start another thread for</div><div>that topic.</div></div><div><br></div><div>Doug</div>
<div><br></div>