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.
- User sends REST API request to Quantum, it is routed to the corresponding Extension and Plugin.
- 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).
- 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.
- The worker scans queue and picks any task for unlocked device. The task is transmitted to Agent
- Agent with help of Driver changes configuration of LB appliance.
- 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.
- 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