Difference between revisions of "Neutron/LBaaS/Architecture/ConcurrentRequests"
< Neutron | LBaaS | Architecture
(talk) |
m (ThierryCarrez moved page Quantum/LBaaS/Architecture/ConcurrentRequests to Neutron/LBaaS/Architecture/ConcurrentRequests) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | = | + | = 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. | |
| − | + | ||
| − | + | {{http://goo.gl/BRUP8}} | |
| − | + | ||
| − | + | # 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 | ||
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.
- 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
