[Feature] Native Floating IP Support and Automated Failover for Octavia Load Balancer

[boombe40]

Description

1. Problem Statement

• Currently, integrating OpenStack Octavia with OpenSDN in External Load Balancer mode presents two critical challenges:

  • Connectivity Failure via Neutron API: Associating a Floating IP (FIP) with an Octavia VIP port using standard Neutron API commands does not establish end-to-end connectivity to Amphora VMs. This occurs because the SDN Fabric fails to route traffic when the FIP object lacks the mandatory virtual-machine-interface-refs for both the VIP and VRRP interfaces.

  • Disruption during Failover: When Octavia triggers a failover, it spawns new Amphora VMs with new VMI IDs while decommissioning the old ones. Consequently, the existing FIP mapping becomes stale, leading to immediate service downtime until the SDN configuration is manually updated.

2. Current Workaround

• To maintain service availability, we are forced to bypass the Neutron API and interface directly with the OpenSDN Config API to perform the following:
  • Manually inject the Octavia Amphora VRRP port into the virtual-machine-interface-refs of the FIP object.
  • Apply custom annotations to the FIP object (e.g., lb_id = <LoadBalancer_UUID>) to track relationships.
  • Deploy an external "Watcher" script (via Cronjob) to poll FIP objects and re-map them to new VMIs during failover events. This introduces significant architectural complexity and unacceptable propagation latency ($10s$–$30s$)

Proposed Solution: Native Integration via virtual-ip Abstraction

To achieve sub-second failover and native integration, I propose utilizing the existing virtual-ip object in the OpenSDN Schema as an abstraction layer between the FIP and the VMIs.

• Technical Architecture Changes:
  A. OpenSDN Neutron Plugin

  • Logic: Implement auto-detection for Octavia VIP ports by inspecting the device_owner attribute.
  • Behavior: When a FIP is associated with a VIP port, the plugin should create or update a virtual-ip object and link the FIP to this object, rather than creating a direct VMI reference.

  B. Schema Transformer & API Server

  • Validation: Ensure the schema fully supports floating-ip-refs within the virtual-ip object.
  • Auto-Population: Enable the Schema Transformer to maintain implicit links between Amphora VMIs and the virtual-ip object whenever allowed-address-pairs are detected.

  C. Service Monitor (svc-monitor)

  • Dynamic Ref Updates: Enhance svc-monitor to track the lifecycle of Octavia VMIs.
  • Traffic Steering: Upon failover, svc-monitor should automatically update the virtual-machine-interface-refs within the virtual-ip object. This allows the vRouter to update the Flow Table at the fabric level instantly, keeping the FIP reference immutable and the transition seamless.

Benefits

• Native Compatibility: Allows users to use standard OpenStack Neutron commands.
• High Availability: Provides sub-second failover without relying on external polling scripts.
• Reduced Complexity: Eliminates the need for out-of-band configuration management and custom annotations on SDN objects.

ref

• https://docs.opensdn.io/opensdn-feature-architecture-guide/load-balance-as-service-vnc.html
• https://github.com/OpenSDN-io/tf-api-client/blob/master/schema/yaml/virtual-ip-schema.yml

[boombe40]

@jayGetsuka

[jayGetsuka]

Thanks @boombe40. Happy to discuss the technical details or implementation of this proposal with the community.

[mkraposhin]

@salimep

[mkraposhin]

@boombe40 , yml files are generated from .xsd, therefore it's better to reference the corresponding schema file too.

[jayGetsuka]

Hi @mkraposhin,

Thanks for the guidance. I’ve reviewed loadbalancer.xsd in the tf-api-client repo.

The VirtualIpType (around line 189) already defines the necessary structure to hold a VIP address and manage member associations.

Technical Confirmation: My proposal is to allow Floating IP to associate directly with this VirtualIp object instead of a specific VMI. Since the VirtualIp is a persistent logical entity, the FIP mapping remains intact even when Octavia spawns a new Amphora. We only need to update the virtual-machine-interface-refs within the VirtualIp object, achieving native, sub-second failover without external scripts.

Looking forward to your thoughts on implementing this association logic.

ref: https://github.com/OpenSDN-io/tf-api-client/blob/master/schema/loadbalancer.xsd