Revision as of 22:03, 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.

File:ApiFlow$api.png

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.

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...