Open Stack

On 01/12/12 16:16 +0100, guillaume pernot wrote:
>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

I have implemented in this style, just not the selection part and I currently only
have support for "=" at the moment, but what you have there looks like a neat extension.

Our current API will look like this:
/projects/1234/meters/cpu_util/volume/sum?metadata.image_id=whatever&timestamp_start=<>&timestamp_stop=<>

To totally embrace this might mean waiting until the v2 api.

/meters?q=sum(cpu_util)&metadata.image_id=whatever&timestamp>=X&timestamp<=&project=1234

We will have to see how the other developers like it.

-Angus
>
>my 2cts,
>guillaume pernot
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev