Difference between revisions of "Neutron/LBaaS/Architecture/Scheduler"
< Neutron | LBaaS | Architecture
Line 15: | Line 15: | ||
* The request to create pool is is received by LBaaS Plugin | * The request to create pool is is received by LBaaS Plugin | ||
* LBaaS Plugin calls DB plugin to create model and store it to DB, pool_id is returned | * LBaaS Plugin calls DB plugin to create model and store it to DB, pool_id is returned | ||
− | |||
* LBaaS Plugin calls Scheduler and passes it service_type, pool_id, pool and other optional parameters. | * LBaaS Plugin calls Scheduler and passes it service_type, pool_id, pool and other optional parameters. | ||
* Scheduler finds device that satisfies service_type and parameters, including those specified in pool. | * Scheduler finds device that satisfies service_type and parameters, including those specified in pool. | ||
* Scheduler stores mapping between device_id and pool_id in its DB. This mapping will be used in latter requests | * Scheduler stores mapping between device_id and pool_id in its DB. This mapping will be used in latter requests | ||
* Scheduler returns device_info to LBaaS plugin | * Scheduler returns device_info to LBaaS plugin | ||
+ | * LBaaS Plugin responds to API with "HTTP 202 Accepted". The rest of process is done asynchronously | ||
* LBaaS plugin sends rpc message to Agent, specifying command, service_type, logical object (pool) and physical object (device parameters) | * LBaaS plugin sends rpc message to Agent, specifying command, service_type, logical object (pool) and physical object (device parameters) | ||
* Agent reads message and forwards it to driver | * Agent reads message and forwards it to driver | ||
Line 33: | Line 33: | ||
[[Media:Quantum$$LBaaS$$Architecture$$Scheduler$Components|diagramm.png]] | [[Media:Quantum$$LBaaS$$Architecture$$Scheduler$Components|diagramm.png]] | ||
+ | |||
+ | '''Where''': | ||
+ | |||
+ | * Dev handler - a part of device specific code which evaluates device of specific type against provided resource; pool in case of loadbalancer service) | ||
+ | * Agent loads sets of drivers which responsible not only for service-specific device configuration, but also for device-management functions, e.g. code that configures VLANs on device, and other tasks needed to wire it to tenant network. |
Revision as of 19:12, 6 December 2012
Overview
Scheduler/Device Management is a separate Quantum plugin. It is responsible for:
- Management of devices that implement advanced services (load balancers, firewalls, vpn gateways, etc). That includes REST API for CRUD operations on device database.
- Binding of service's logical models to devices (ex: schedule vip to load balancer)
Workflow
Example 1. The typical workflow for vip creation:
Details:
- The request to create pool is is received by LBaaS Plugin
- LBaaS Plugin calls DB plugin to create model and store it to DB, pool_id is returned
- LBaaS Plugin calls Scheduler and passes it service_type, pool_id, pool and other optional parameters.
- Scheduler finds device that satisfies service_type and parameters, including those specified in pool.
- Scheduler stores mapping between device_id and pool_id in its DB. This mapping will be used in latter requests
- Scheduler returns device_info to LBaaS plugin
- LBaaS Plugin responds to API with "HTTP 202 Accepted". The rest of process is done asynchronously
- LBaaS plugin sends rpc message to Agent, specifying command, service_type, logical object (pool) and physical object (device parameters)
- Agent reads message and forwards it to driver
- Driver is responsible to wire device to tenant network according to service insertion mode and deploy logical object to the device
- Agent returns result to LBaaS plugin which updates state of corresponding DB object.
Important note: Agent is common for all services. It delegates processing to drivers[service_type][device_type][version].
See also Scheduler API
Whole component diagram:
Where:
- Dev handler - a part of device specific code which evaluates device of specific type against provided resource; pool in case of loadbalancer service)
- Agent loads sets of drivers which responsible not only for service-specific device configuration, but also for device-management functions, e.g. code that configures VLANs on device, and other tasks needed to wire it to tenant network.