- 1 Scope
- 2 Use Cases
- 3 Implementation Overview
- 4 Data Model Changes
- 5 Configuration variables
- 6 API's
- 7 CLI Requirements
- 8 Horizon Requirements
There are two more service agents planned to be added in Havana release. The goal of this blueprint is to specify common architecture for all service agents and show how existing agent-scheduler framework may be used. The new service agent will be used as a base for lbaas, vpnaas, fwaas agents.
Note. Here and below the term 'resource object' means the root object of service model (e.g. VIP in case of LBaaS, vpn_connections in case of VPNaaS). Term 'appliance' represents machine/process where service runs.
From deployment perspective appliance can be:
1) on-host process - ex. haproxy as process on network controller or dedicated node with running haproxy 2) VM running on compute node 3) physical appliance
Use case 1. Load balancing using 3 nodes with HAProxy processes
* Enable 'lbaas-haproxy-namespace-agent' on every host * Configure the scheduler (similar to what is done for L3 and DHCP agents) * Register agents * Create LB logic objects. Once VIP is created the agent scheduler picks the agent and binds them. The agent compiles logic model into haproxy configuration and launches process (the way it is done in Grizzly reference implementation)
In this use case there will be one agent per node
Use case 2. Load balancing using F5 hardware balancers
* Enable 'lbaas-f5-agent' on network controller (here instead of specific lbaas-f5-agent we may have lbaas-agent with f5 driver). The agent is configured with the list of devices. The configuration may be static (via conf file) or exposed via API (like those for l3-agent and dhcp-agent) * Configure the scheduler. Here a specific scheduler may be chosen - the one that is aware of devices state and their capacity.
Use case 3. VPN tunnel is created
* Enable 'vpnaas-agent' on network node * Configure the scheduler with specific VPNaaS-aware scheduler
The agent scheduler framework already introduces parts needed for implementation: pluggable scheduling algorithm, API extensions, l3-agent and dhcp-agent may be used as reference point.
From code perspective the changes are:
1. Introduce new type of agent (for lbaas we can base on reference implementation of lbaas-agent) 2. Introduce new scheduling algorithm that takes into account capabilities of appliance, their load, etc. 3. Introduce reporting protocol between agent and agent scheduler 4. Introduce API for service agent just like it is done for l3-agent and dhcp-agent. This API may support operations for managing list of devices.
The architecture is following:
Data Model Changes
Introduce new tables for storing binding between resource object and agent. As an option we may think of refactoring existing NetworkDhcpAgentBinding and RouterL3AgentBinding into common model.
quantum.conf: variable to configure scheduler for service agent. service-agent.conf
API to configure list of devices for device-oriented service agent. But this is not top priority for the first version as devices may be configured statically.
CLI for device configuration (optional)