Difference between revisions of "Obsolete:Ceilometer/blueprints/APIv2"
| Line 5: | Line 5: | ||
== Summary == | == 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. | ||
| + | |||
| + | |||
| + | <pre><nowiki> | ||
| + | So: | ||
| + | /resources?source=elsewhere | ||
| + | rather than | ||
| + | /sources/elsewhere/resources | ||
| + | </nowiki></pre> | ||
| + | |||
== Release Note == | == Release Note == | ||
| Line 16: | Line 30: | ||
* '''Resource''' is an openstack object created for a user (eg. instance, volume) | * '''Resource''' is an openstack object created for a user (eg. instance, volume) | ||
* '''User''' is an openstack user auth'ed by keystone | * '''User''' is an openstack user auth'ed by keystone | ||
| − | * '''Source''' is the origin of a sample (usually "openstack"). | + | * '''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) | * '''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:-) | * '''Counter''' is a type of Meter that counts upwards (car: distance travelled - assume you don't reverse a lot:-) | ||
| − | |||
| − | |||
| − | |||
| − | |||
== User stories == | == User stories == | ||
| − | + | == Assumptions == | |
| − | = | + | * Resources are implicitly created by creating new Meters |
| + | * Passing arrays needs to be done like this ''class[index].property=value'' | ||
== Design == | == Design == | ||
| + | |||
| + | {| border="1" cellpadding="2" cellspacing="0" | ||
| + | | 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: | ||
| + | |||
| + | <pre><nowiki> | ||
| + | q[].field=name | ||
| + | q[].op=eq | ||
| + | q[].value=56 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | ''op'' is the comparison operation (eq, gt, lt, etc) | ||
| + | |||
| + | Field Selection | ||
| + | |||
| + | <pre><nowiki> | ||
| + | s[].name=field | ||
| + | </nowiki></pre> | ||
| + | |||
| + | 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 == | == Implementation == | ||
| Line 43: | Line 113: | ||
== Unresolved issues == | == Unresolved issues == | ||
| + | Do we need to keep the following queries: | ||
| + | |||
| + | <pre><nowiki> | ||
| + | /sources | ||
| + | /projects | ||
| + | /users | ||
| + | </nowiki></pre> | ||
| + | |||
| + | Basically are these queries been used at the moment? | ||
== BoF agenda and discussion == | == BoF agenda and discussion == | ||
Revision as of 04:08, 6 December 2012
- 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.
