Bug 1042274

Summary: [RFE][ceilometer]: Selectable aggregation functions on statistics queries
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: openstack-ceilometerAssignee: RHOS Maint <rhos-maint>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, jruzicka, markmc, pbrady, yeylon
Target Milestone: gaKeywords: FutureFeature
Target Release: 5.0 (RHEL 7)   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/ceilometer/+spec/selectable-aggregates
Whiteboard: upstream_milestone_icehouse-3 upstream_status_implemented upstream_definition_approved
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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