Jump to: navigation, search

Difference between revisions of "ApiFlow"

(Mocking up my thoughs on API flow control)
 
m
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
 
  
 
= 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.
 +
 +
[[Image: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 ==
 +
* 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...
 +
 +
[[Category: nova]]

Latest revision as of 18:48, 9 January 2015

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.

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

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