Difference between revisions of "Obsolete:Ceilometer/blueprints/APIv2"
(responding to questions) |
|||
Line 89: | Line 89: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | s[] | + | s[]=field |
</nowiki></pre> | </nowiki></pre> | ||
This is a way to choose the field that get returned. If you leave this out we default to returning all 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 === | === Resource Resources === | ||
Line 122: | Line 120: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | c[] | + | c[]={sum|max|min|ave|len} |
</nowiki></pre> | </nowiki></pre> | ||
− | |||
− | |||
The period is to define the time period over which to calculate the above values. | The period is to define the time period over which to calculate the above values. | ||
Line 148: | Line 144: | ||
q[2].op=gt& | q[2].op=gt& | ||
q[2].value=<now - 5 hours>& | q[2].value=<now - 5 hours>& | ||
− | c[0] | + | c[0]=max& |
− | c[1] | + | c[1]=min& |
− | c[2] | + | c[2]=ave& |
period=360 | period=360 | ||
</nowiki></pre> | </nowiki></pre> | ||
Line 195: | Line 191: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | c[0] | + | c[0]=max&c[1]=min&c[2]=ave& |
</nowiki></pre> | </nowiki></pre> | ||
Line 202: | Line 198: | ||
I'm not sure how useful it is, and am a little concerned about how good performance will be. I think it's OK to include them now, or we could experiment with performance and possibly change the storage API to support having multiple calculations performed at one time in the database then add the feature later. - dhellmann | I'm not sure how useful it is, and am a little concerned about how good performance will be. I think it's OK to include them now, or we could experiment with performance and possibly change the storage API to support having multiple calculations performed at one time in the database then add the feature later. - dhellmann | ||
− | '''QU: The API | + | '''QU: The API includes passing a period over which Calculations are done''' |
− | + | ||
+ | This produces output like: | ||
<pre><nowiki> | <pre><nowiki> | ||
Line 215: | Line 212: | ||
Do you have ideas for how to implement this? I think I can envision how to do it in a clumsy way with mapreduce, but I don't know about the SQL. - dhellmann | Do you have ideas for how to implement this? I think I can envision how to do it in a clumsy way with mapreduce, but I don't know about the SQL. - dhellmann | ||
+ | |||
+ | Well we could split up the periods in the api, then the db could return all statistical calculations for that one period. | ||
+ | |||
+ | So the db api could look like: | ||
+ | |||
+ | <pre><nowiki> | ||
+ | def get_samples(meter, query): | ||
+ | '''just return the raw samples that match the query''' | ||
+ | def get_statistics(meter, query): | ||
+ | '''return (max,min,avg,len,duration) for the given query''' | ||
+ | </nowiki></pre> | ||
+ | |||
== BoF agenda and discussion == | == BoF agenda and discussion == |
Revision as of 23:00, 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
Note I started with this:
https://github.com/asalkeld/ceilometer/commit/c678ff8abd2a91c4404657748b9ed9b31c1541df
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
- The relationship between objects does not change (resource -> meter -> sample)
So the same db schema (at least in mongo)
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[]=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
So just a resource_id makes the resource unique.
Meter Resources
GET /v2/meters
Returns a list of available meters that match the Query (if given).
POST /v2/meters
The body:
GET /v2/meters/<meter>
Get the meter samples match the Query (if given) and return either raw samples or derived statistics depending on the Computation and Period.
Computation (acts on value/volume and assumes a period)
c[]={sum|max|min|ave|len}
The period is to define the time period over which to calculate the above values.
Period
Example:
/v2/meters/cpu_util? q[0].field=metadata.autoscale_group& q[0].op=eq& q[0].value=all_mine& q[1].field=timestamp& q[1].op=lt& q[1].value=<now>& q[2].field=timestamp& q[2].op=gt& q[2].value=<now - 5 hours>& c[0]=max& c[1]=min& c[2]=ave& period=360
The above gets all the cpu_util samples with metadata.autoscale_group=all_mine between 5hours ago and now. Then calulates the min, max and avg for each hour. This would return something like this:
{[ {min=12, max=34, avg=23}, {min=14, max=41, avg=26}, {min=15, max=43, avg=29}, {min=16, max=44, avg=34}, {min=18, max=47, avg=33}, ]}
Implementation
UI Changes
Code Changes
Migration
Test/Demo Plan
Unresolved issues
QU: Do we need to keep the following queries:
/sources /projects /users
Basically are these queries been used at the moment?
The DUDE lists resources in a project and then asks questions about the meters reporting data for the resource. We do not use these queries. - dhellmann
QU: The API about includes passing multiple Calculations like:
c[0]=max&c[1]=min&c[2]=ave&
Do you think this is a good idea?
I'm not sure how useful it is, and am a little concerned about how good performance will be. I think it's OK to include them now, or we could experiment with performance and possibly change the storage API to support having multiple calculations performed at one time in the database then add the feature later. - dhellmann
QU: The API includes passing a period over which Calculations are done
This produces output like:
{[ {min=12, max=34, avg=23}, {min=14, max=41, avg=26}, ...
Is this neat/super useful or unnecessary?
Do you have ideas for how to implement this? I think I can envision how to do it in a clumsy way with mapreduce, but I don't know about the SQL. - dhellmann
Well we could split up the periods in the api, then the db could return all statistical calculations for that one period.
So the db api could look like:
def get_samples(meter, query): '''just return the raw samples that match the query''' def get_statistics(meter, query): '''return (max,min,avg,len,duration) for the given query'''
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.