Difference between revisions of "Ceilometer/blueprints/api-group-by"

Revision as of 17:33, 15 January 2013

Summary

The API should allow to do GROUP BY type operation.

User stories

I had an instance running for 6h. It started as a m1.tiny flavor during the first 2 hours and then grew up to a m1.large flavor for the next 4 hours. I need to get this two durations so I can bill them with different rates.

Design

Enhance API v2 so it implements a new arguments to do GROUP BY operations.

For exemple add:

g[].field=<field name>

g can be a list of strings, so it doesn't need the ".field" part -- dhellmann

That solves the user story above with:

/v2/meters/instance?
 q[0].field=resource&
 q[0].op=eq&
 q[0].value=<my-resource-id>&
 q[1].field=timestamp&
 q[1].op=lt&
 q[1].value=<now>&
 q[2].field=timestamp&
 q[2].op=gt&
 q[2].value=<now - 6 hours>&
 g[0].field=metadata.flavor&
 c[0]=sum&
 period=360

Would return

{[
  { "m1.tiny": 1 },
  { "m1.tiny": 1 },
  { "m1.large": 1 },
  { "m1.large": 1 },
  { "m1.large": 1 },
  { "m1.large": 1 },
]}

Each return value should include the time range for the accounting systems to record. It may be simpler to just extend the statistics API we have (without the "c" argument), and adding a "g" field with the grouping column names and values so the recipient can figure out what each result means. -- dhellmann

Further more, dropping the q[0] request that narrows the search to only one resource allows to retrieve this information for all instances over that period of time:

/v2/meters/instance?
 q[0].field=timestamp&
 q[0].op=lt&
 q[0].value=<now>&
 q[1].field=timestamp&
 q[1].op=gt&
 q[1].value=<now - 6 hours>&
 g[0].field=metadata.flavor&
 c[0]=sum&
 period=360

I think you need to add another value to g to express that you want to group by the "resource_id" field, too. -- dhellmann

If there was another large instance, that would return:

{[
  { "m1.tiny": 1, "m1.large": 1 },
  { "m1.tiny": 1, "m1.large": 1 },
  { "m1.large": 2 },
  { "m1.large": 2 },
  { "m1.large": 2 },
  { "m1.large": 2 },
]}

Be careful that specifying a c[] is mandatory in a GROUP BY operation (as in SQL).

@@ Line 18: / Line 18: @@
 </nowiki></pre>
+g can be a list of strings, so it doesn't need the ".field" part -- dhellmann
 That solves the user story above with:
@@ Line 52: / Line 54: @@
 </nowiki></pre>
+Each return value should include the time range for the accounting systems to record. It may be simpler to just extend the statistics API we have (without the "c" argument), and adding a "g" field with the grouping column names and values so the recipient can figure out what each result means. -- dhellmann
 Further more, dropping the q[0] request that narrows the search to only one resource allows to retrieve this information for all instances over that period of time:
@@ Line 68: / Line 72: @@
 </nowiki></pre>
+I think you need to add another value to g to express that you want to group by the "resource_id" field, too. -- dhellmann
 If there was another large instance, that would return: