Bug 1042274 - [RFE][ceilometer]: Selectable aggregation functions on statistics queries
Summary: [RFE][ceilometer]: Selectable aggregation functions on statistics queries
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-ceilometer
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ga
: 5.0 (RHEL 7)
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/ceil...
Whiteboard: upstream_milestone_icehouse-3 upstrea...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 21:36 UTC by RHOS Integration
Modified: 2014-09-08 05:42 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 21:36:38 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/ceilometer/+spec/selectable-aggregates.

Description:

Currently, all statistcs queries return *all* available aggregates, i.e. the results of the standard set of aggregation functions: avg, sum, min, max, count.

This is acceptable for a limited set of aggregates, there's not necessarily much additional computation overhead involved and in some cases the calculation of one aggregate naturally "falls out" of another (e.g. count from average).

However as the range of aggregates becomes wider, e.g. to include more expensive functions such as percentiles, then it would be better to also the API caller specify which aggregate functions they're interested in.

One way of doing so would be via the WSME query mechanism, using 'aggregate' as a distinguished field, e.g.:

  /v2/meter/cpu/statistics?q.field=aggregate&q.op=eq&q.value=max,stddev,count

The API contract would be such that some super-set of the requested aggregate functions are returned. In the case where pre-aggregated values are available for the appropriate scope, periodicity etc., then more aggregates than requested may be returned (i.e. there wouldn't be a great need to scrub these data of unrequested aggregate values). Where one of more of the requested aggregates are unsupported, then this would be indicated via a 400 Bad Request response with an appropriate log message.  

Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.