Difference between revisions of "ApiFlow"
| Line 13: | Line 13: | ||
** nova.api.openstack.ratelimiting:[[RateLimitingMiddleware]] | ** nova.api.openstack.ratelimiting:[[RateLimitingMiddleware]] | ||
** '''Proposed changes:''' | ** '''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 | ||
| + | ** Needs to be changed to store statistics in database for multi-node deployments. | ||
| + | * Compute API Authentication Code | ||
| + | ** 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 Rate Limiting Code | ||
| + | ** 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... | ||
Revision as of 22:02, 7 February 2011
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 Code
- 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 Rate Limiting Code
- 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...
