End of Software Development for F5 OpenStack LBaaS version 1
F5 announces the End of Software Development (EoSD) for the F5 OpenStack LBaaS version 1 integration, effective October 1, 2016. This announcement is in compliance with the OpenStack community deprecation of the OpenStack Neutron LBaaS version 1 plugin. Customers are encouraged to move to OpenStack LBaaS version 2.
F5 will continue to repair defects and perform maintenance on the F5 OpenStack LBaaS version 1 integration until the Openstack Ocata release in April 2017.
For additional information, please refer to the F5 OpenStack Releases and Support Matrix.
When Neutron LBaaSv1 API calls are issued to your Neutron controller, the community LBaaSv1 plugin attempts to use either a designated service provider driver or the default service provider driver to provision LBaaSv1 resources.
F5® LBaaSv1 Plugin¶
The F5® LBaaSv1 service provider driver runs within the Neutron controller processes. It utilizes Neutron RPC messaging queues to issue provisioning tasks to F5® LBaaSv1 agent processes.
When an LBaaSv1 API interface is invoked, the F5® LBaaSv1 driver schedules tasks to an F5® agent based on the agent’s availability (determined from the standard Neutron agent status messages). The agent starts, and communicates with, a configured BIG-IP®, then registers its own named queue where it will receive tasks from the Neutron controller(s).
The The F5® agent makes callbacks to the F5® drivers to query additional Neutron network, port, and subnet information; allocate Neutron objects (for example, fixed IP addresses); and report provisioning and pool status. These callback requests are placed on an RPC message queue processed by all listening F5® drivers in a round robin fashion. Since all Neutron controller processes are working transactionally off the same backend database, it doesn’t matter which of the available Neutron controller processes handles the requests.
F5® LBaaSv1 Driver and Agent Placement¶
The F5® LBaaSv1 driver should be installed on at least one Neutron controller. Installing drivers on additional controllers scales out communications to Neutron.
The F5® LBaaSv1 agent should be installed on at least on Neutron controller. Installing additional agents on different hosts in the same BIG-IP® environment (in other words, hosts that have the same BIG-IP®
environment_prefix and iControl® endpoint settings) adds scheduled redundancy to the provision process. See BIG-IP® Environments for more information.
Neutron Agent Binding¶
Neutron LBaaSv1 binds pools to specific agents for the life of the pool. The redundancy allows other agents running in the same environment to handle requests if the bound agent is not active.
If the bound agent is inactive, it’s expected that it will be brought back online. If an agent is deleted, all pools bound to it should also be deleted. Run
neutron lb-pool-list-on-agent <agent-id> to identify all pools associated with an agent.
Two agents which have different iControl® endpoint settings (in other words, agents that are provisioning different sets of BIG-IP® devices) can not be configured with the same
The scheduler uses the
environment_prefix as a unique identifier for the agent process. If you use the same
environment_prefix for two agents that are managing separate BIG-IP® devices, the scheduler will confuse them, most likely resulting in errors.
See Running Multiple Agents on the Same Host for more information.
You can check the status of all running Neutron agent processes via the Neutron API agent interfaces, or by using the commands shown below in the CLI client.
# neutron agent-list # neutron agent-show <agent_id>