Neutron/ServiceAgent

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

Use Cases
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

Figure 1. Service agent deployment


In this deployment user has 1 network controller, 2 dedicated hosts where haproxy-namespace agent run, 1 host with F5 agent and 2 HW LBs managed by F5 agent.

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)

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 that 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

Implementation Overview
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-namespace-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:

Figure 2. Plugin and agent architecture


Note. There are options on agent implementation: mixin with specific service implementations or extension-per-service.

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.

Configuration variables

 * quantum.conf: variable to configure scheduler for service agent.
 * service-agent.conf

API's
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 Requirements
CLI for device configuration (optional)

Horizon Requirements
'tbd'