Difference between revisions of "ApiFlow"
m |
|||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ||
= API Flow Proposal = | = API Flow Proposal = | ||
As an example I'll detail a user's POST request to the /servers module. Historically this was a very intensive and heavily monitor action and as such heavy rate limits were imposed. | As an example I'll detail a user's POST request to the /servers module. Historically this was a very intensive and heavily monitor action and as such heavy rate limits were imposed. | ||
| − | [[Image: | + | [[Image:api.png]] |
== HTTP API Authentication Middleware == | == HTTP API Authentication Middleware == | ||
| Line 19: | Line 19: | ||
* Needs to be changed to store statistics in database for multi-node deployments. | * Needs to be changed to store statistics in database for multi-node deployments. | ||
| − | == Compute API Authentication | + | == Compute API Authentication == |
* Already in place...sort of... | * Already in place...sort of... | ||
* [[RequestContext]] is passed in and used in some cases | * [[RequestContext]] is passed in and used in some cases | ||
| Line 27: | Line 27: | ||
** Standard exceptions should be raised when authentication fails. | ** Standard exceptions should be raised when authentication fails. | ||
| − | == Compute API Rate Limiting | + | == Compute API Quota Checking == |
| + | * Already in place. | ||
| + | * In many calls such as create(), quotas are checked. | ||
| + | * '''No proposed changes.''' | ||
| + | |||
| + | == Compute API Rate Limiting == | ||
* Does not exist | * Does not exist | ||
* Would need to store information in database for multi-node deployments. | * Would need to store information in database for multi-node deployments. | ||
| Line 36: | Line 41: | ||
** # of delete() calls per project | ** # of delete() calls per project | ||
** etc... | ** etc... | ||
| + | |||
| + | [[Category: nova]] | ||
Latest revision as of 18:48, 9 January 2015
Contents
API Flow Proposal
As an example I'll detail a user's POST request to the /servers module. Historically this was a very intensive and heavily monitor action and as such heavy rate limits were imposed.
HTTP API Authentication Middleware
- Already in place
- nova.api.openstack.auth:AuthMiddleware
- No proposed changes.
HTTP API Rate Limiting Middleware
- Already in place
- nova.api.openstack.ratelimiting:RateLimitingMiddleware
- Proposed changes:
- This middleware is in place to save us from overloading the HTTP API servers. As such it doesn't seem like the right place to be rate limiting based on the load/abilities of the Compute API. I would recommend this layer deal solely with the following limits:
- # of requests per user
- # of requests per project
- This middleware is in place to save us from overloading the HTTP API servers. As such it doesn't seem like the right place to be rate limiting based on the load/abilities of the Compute API. I would recommend this layer deal solely with the following limits:
- Needs to be changed to store statistics in database for multi-node deployments.
Compute API Authentication
- Already in place...sort of...
- RequestContext is passed in and used in some cases
- Proposed changes:
- No such thing as an unauthenticated request.
- Context should be fully filled out and validate in each Compute API call.
- Standard exceptions should be raised when authentication fails.
Compute API Quota Checking
- Already in place.
- In many calls such as create(), quotas are checked.
- No proposed changes.
Compute API Rate Limiting
- Does not exist
- Would need to store information in database for multi-node deployments.
- Deals with:
- # of create() calls per user
- # of delete() calls per user
- # of create() calls per project
- # of delete() calls per project
- etc...
