Open Stack

hi,

reading
https://blueprints.launchpad.net/ceilometer/+spec/multi-dimensions , I
would like to share my thoughts about a DAP-inspired syntax for queries.

Data Access Protocol
(http://earthdata.nasa.gov/our-community/esdswg/standards-process-spg/rfc/esds-rfc-004-dap-20)
defines a way to build quite versatile queries. Its general form is
`q=<projection>&<selection>`, where <projection> is a coma-separated
list of wanted meters (possibly aggregated with sum(), max(), count(),
etc...), and <selection> is an &-separated list of conditions.

eg:

 ?q=instance.id&instance.cpu_util>=0.95 : return instances that have a cpu-load superior to 0.95 (eg : red alert)

 ?q=instance.name,instance.cpu_util&instance.cpu_util>=0.85&instance.cpu_util<0.95 }}}: return (instance name, cpu load) for instances where cpu load is between 0.85 and 0.95 (eg : orange warning)

 ?q=instance.id,sqrt(instance.cpu_util) : return (id, square root of cpu load) for each instance (per-element computation). yeah, sqrt(cpu_util) is not really meaningful...

 ?q=avg(instance.cpu_util)?instance.name~=foo.* : return the average cpu load of all instances that name matches regexp "foo.*" (aggregation)

>From the blueprint use cases :
 John should query : ?q=sum(container.objects)&container.name=xxx
 Peter should query : ?q=sum(instance.cpu)&instance.type=yyyy
 Andrew should query : ?q=max(instance.cpu)&instance.id={17,42,128}

Pros:
 - mongodb knows how to handle this efficiently, taking the best out of map/reduce
 - selective : users query is as much selective as possible (limiting client-side post-processing)
 - versatile : a wide range of computations/selections can be performed this way
Cons:
 - increased implementation complexity
 - maybe overkill

my 2cts,
guillaume pernot