Neutron/LBaaS/Architecture/ConcurrentRequests

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


 * 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