Octavia Provider Driver for F5 BigIP devices

This is the Octavia provider driver for F5 BigIP appliances. It communicates with BigIP devices via the declarative AS3 API. The worker uses the driver-agent API, but it hooks more deeply into Octavia (similar to the Octavia Amphora driver) than the Provider Agents concept permits, e. g. by accessing the database directly.

Modules

• octavia_f5/api: Driver, running in Octavia main process (extends AmphoraProviderDriver)
• octavia_f5/cmd: Entry points for house-keeping and status manager.
  • house_keeping: DB cleanup. Uses Octavia class DatabaseCleanup
• octavia_f5/controller: Communication with BigIP device
  • status_manager: Manages table entries representing BigIP devices
  • controller_worker: REST endpoints for Octavia, synchronization loop
  • sync_manager: Builds AS3 declarations and sends them to the BigIP device.
  • status: Methods for setting status in database. Used by controller_worker.
• db: Repository classes (CRUD abstractions over sqlalchemy ORM objects)
• network: Layer 2 network drivers (Neutron hierarchical port binding driver, no-op driver)
• restclient: Classes for building AS3 declarations. Used by sync_manager and status_manager.

Special database handling

This provider driver uses Octavias mariadb database to store some data, but doesn't define any new tables. Instead, otherwise unused tables are used in a specific way:

• The amphora table is used in two ways:
  • For each load balancer an amphora entry is created. This is done to prevent problems with Octavias health manager, which makes assumptions about amphora entries.
    • compute_flavor holds the name of the device the load balancer is scheduled to. This can be used to query the device via openstack loadbalancer amphora show $LB_ID.
    • Since an amphora table entry is never updated as long as its respective load balancer lives, the updated_at field will always be null until the load balancer is being deleted, which will update the amphora entry status to DELETED as well.
  • For each F5 device that is managed by a provider driver worker a special entry is created in the amphora table.
    • compute_flavor holds the name of the managed F5 device
    • cached_zone holds the hostname
    • load_balancer_id will always be null
    • role (must contain one of the values defined in the amphora_roles table) holds information about whether the device is in active status (MASTER) or standby status (BACKUP)
    • status (must contain one of the values defined in the provisioning_status table) holds device state.
      • ALLOCATED means the the device is offline (no entry in device status response)
      • READY means the device is online
      • BOOTING if it was offline and is now back online. In this case the device receives a full sync and the status is set to READY.
    • If vrrp_interface is set to 'disabled' for a given F5 amphora entry, the scheduler will not take that device into account when scheduling new load balancers.
    • vrrp_priority holds the amount of listeners on that device

F5-specific configuration options

There are lots of F5-specific configuration options. They can be found in octavia_f5/common/config.py.

• If agent_scheduler in the [networking] section of the configuration is set to loadbalancer, new load balancers are scheduled to the device with the least load balancers. This is the default. If it is set to listener, new load balancers are scheduled to the device with the least listeners.

Listener type to AS3 service class mapping

Mapping happens in octavia_f5/restclient/as3objects/service.py.

Openstack listener type	AS3 service class	Notes
TCP	Service_L4	Uses L4 acceleration
UDP	Service_UDP
HTTP	Service_HTTP
HTTPS	Service_L4	Uses L4 acceleration, since HTTPS simply gets passed through without decryption
PROXY	Service_TCP	Does not use L4 acceleration, since it's incompatible with the Proxy Protocol iRule
TERMINATED_HTTPS	Service_HTTPS