The Octavia v2 API served by neutron-api; OVN load balancers, enabled by default.
Go OVN load balancersopenkeel-ovn-octavia-provider
The module
OpenKeel implementation in Go of OpenStack ovn-octavia-provider, generated from the reverse-specification of branch stable/2026.2 by the generate-go-from-spec skill. It is the OVN load-balancing back end of OpenKeel's Octavia API: each load balancer becomes rows of the OVN Northbound Load_Balancer table, with the same keys and statuses as the Python provider, so that clients, Neutron and existing OVN databases see no difference. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md.
okadm install deploys it by default. The public Octavia v2 API lives in the neutron-api binary of openkeel-neutron, under /load-balancer, and Neutron is the only caller of the driver API. The provider sends status updates and reads objects back over HTTP, to Neutron's admin port. See docs/DEPLOYMENT.md.
The Python shim and the octavia-driver-agent sidecar (off by default) stay in this project only to take over from a Python Octavia; they are not part of OpenKeel's normal path.
Go module: github.com/openkeel/openkeel-ovn-octavia-provider
Binaries: ovn-octavia-provider (driver API on port 9877, health and metrics on 9090) and octavia-ovn-db-sync-util
Python shim, to take over from a Python Octavia: shim/, entry point octavia.api.drivers = ovn
Configuration: YAML, see config/config.example.yaml
State: none of its own, the OVN NB database is the database, so there are no migrations
Development environment and tests: docs/GETTING-STARTED.md
Excerpt from openkeel-ovn-octavia-provider/README.md (in English).
REST API
297 operations of the original REST API (routes and body actions), and their state in OpenKeel. Served by neutron-api (openkeel-neutron, internal/lbaas).
The Go provider is run step by step next to the real Python provider on the same OVN, then checked with octavia-tempest-plugin and real traffic on the lab.
Differential test
Differential against the Python provider
The same 35 steps produce the same OVN rows and status updates from the Python and Go providers on a real OVN.
How it runs
test/ovn/differential/record.py runs the Python driver; TestDifferential plays the same steps on Go and compares.
Latest result 35 / 35 steps identical, apart from one deliberate health monitor status difference (2026-10-31).
The OVN provider becomes a Go service called over HTTP by the Octavia API in neutron-api, without Python driver loading, the driver agent or the Neutron sync plugin.
Internal machinery simplified
Python provider loading and driver agent
Why it was left out
neutron-api is the only caller: it calls the driver over HTTP and receives the status messages on its admin port instead of the driver agent's Unix sockets.
Why the solution is not affected
Load balancers reach ACTIVE through the public Octavia API. A small Python shim exists only to take over from a Python Octavia.