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
- Needs to be changed to store statistics in database for multi-node deployments.
- 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:
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...