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 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) * The
An alternative solution may be based on agent scheduler feature introduced in Grizzly-3. Agent scheduler feature includes infrastructure that supports API extension used for agent configuration, pluggable scheduling algorithms, health monitoring (good blog post on how the scheduler works http://www.mirantis.com/blog/a-new-agent-management-approach-in-quantum-for-openstack-grizzly/)
Agent scheduler -based solution fits to all types of appliances: for type 1 appliances agent is located on the same host that provides service. For type 2 and 3 agent may be a single process per cloud, or as many as needed to have high availability. There may be one class of agent per service type / vendor or common agent extendable with service plugins. Agent may hold list of appliances it configures, that list may be static or configurable via agent API (extension of agent scheduler API).
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.
Implementation Overview: [Provide an overview of the implementation and any algorithms that will be used]
Data Model Changes: [Are you introducing new model classes, or extending existing ones?]
Configuration variables: [List and explanation of the new configuration variables (if they exist)]
API's: [List and explanation of the new API's (if they exist)]
Plugin Interface: [Does this feature introduce any change?]
Required Plugin support: [What should the plugins do to support this new feature? (If applicable)]
Dependencies: [List of python packages and/or OpenStack components? (If applicable)]
CLI Requirements: [List of CLI requirements (If applicable)]
Horizon Requirements: [List of Horizon requirements (If applicable)]
Usage Example: [How to run/use/interface with the new feature. (If applicable)]
Test Cases: [Description of various test cases. (If applicable)]