Jump to: navigation, search

Obsolete:Ceilometer/blueprints/APIv2

Revision as of 04:08, 6 December 2012 by Asalkeld (talk)
  • Launchpad Entry: CeilometerSpec:API v2
  • Created: 6 December 2012
  • Contributors: Angus Salkeld

Summary

Our current API is very nested and looks great as a link, but makes it a bit painful to add new features as they need to be added in so many places. Also the test case blow out too. So lets use optional arguments for filters instead of resource ownership.


So:
 /resources?source=elsewhere
rather than
 /sources/elsewhere/resources


Release Note

Rationale

Terminology

  • Meter == definition of the measurement (name,ownership,resource,metadata) - synonyms (metric)
  • Sample == the actual data values (value,unit,timestamp) synonyms (measurement)
  • Resource is an openstack object created for a user (eg. instance, volume)
  • User is an openstack user auth'ed by keystone
  • Source is the origin of a sample (usually "openstack" but could be a url).
  • Gauge is a type of Meter absolute measurement (car: revs per minute)
  • Counter is a type of Meter that counts upwards (car: distance travelled - assume you don't reverse a lot:-)

User stories

Assumptions

  • Resources are implicitly created by creating new Meters
  • Passing arrays needs to be done like this class[index].property=value

Design

Query Type Resource
GET /resources
GET /resources/<resource_id>
GET /meters
GET /meters/<meter>
POST /meters
PUT /meters/<meter>
DELETE /meters/<meter>

Generic optional arguments

Query:

q[].field=name
q[].op=eq
q[].value=56

op is the comparison operation (eq, gt, lt, etc)

Field Selection

s[].name=field

This is a way to choose the field that get returned. If you leave this out we default to returning all field.

Resource Resources

Same as currently, but we support the following actions

  • listing with the common Query mechanism
  • get a single resource

Meter Resources

Computation (acts on value/volume and assumes a period) c[].name={sum|max|min|ave|len}

Period

Implementation

UI Changes

Code Changes

Migration

Test/Demo Plan

Unresolved issues

Do we need to keep the following queries:

 /sources
 /projects
 /users

Basically are these queries been used at the moment?

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.