Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/Architecture/ConcurrentRequests"

m (Text replace - "__NOTOC__" to "")
 
(No difference)

Latest revision as of 15:54, 21 June 2013

Concurrent REST API requests

There are two types of locks:

  • Object-level lock is done on an instance (vip, pool, member) and restricts concurrent changes. The lock is achieved by moving object into one of PENDING_* states.
  • Device-level lock is done to lock the whole configuration and disallow concurrent changes. Since this is a restrictive policy, requests are actually put into queue and then processed by driver one-by-one. The queue may be implemented completely as Python code or be an external MQ.

The following diagram shows 2 concurrent update requests, 'alt' blocks show processing alternatives for requests.

Template:Http://goo.gl/BRUP8

  1. User sends REST API request to Quantum, it is routed to the corresponding Extension and Plugin.
  2. Plugin performs validation of request (schema conformance, values and references check, etc). If validation succeed, HTTP 202 is returned, if not - one of 40x codes (depending on reason).
  3. DB object is updated and object is moved to PENDING_UPDATE state. Request is transformed into task and pushed into queue. The device corresponding to object is locked.
  4. The worker scans queue and picks any task for unlocked device. The task is transmitted to Agent
  5. Agent with help of Driver changes configuration of LB appliance.
  6. If some other user request arrives to the Plugin it is processed a usual way, except of rejecting attempts to update object in PENDING_UPDATE state. If request succeeds Plugin pushes it into queue. If the request is for the locked device, it remain in the queue until device is unlocked.
  7. Once Agent completes work, it replies Plugin with the status. DB is updated and object is moved into ACTIVE or ERROR state. Device is unlocked.

Diagram source: http://goo.gl/obo1T