Die Octavia-v2-API, bereitgestellt von neutron-api; OVN-Load-Balancer, standardmäßig aktiviert.
Go OVN-Load-Balanceropenkeel-ovn-octavia-provider
Das Modul
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
Auszug aus openkeel-ovn-octavia-provider/README.md (auf Englisch).
REST-API
297 Operationen der Original-REST-API (Routen und Body-Aktionen) und ihr Status in OpenKeel. Bedient von neutron-api (openkeel-neutron, internal/lbaas).
Der Go-Provider wird Schritt für Schritt neben dem echten Python-Provider auf demselben OVN ausgeführt und anschließend mit octavia-tempest-plugin und echtem Traffic im Lab geprüft.
Differenzieller Test
Differenzieller Vergleich mit dem Python-Provider
Dieselben 35 Schritte erzeugen mit dem Python- und dem Go-Provider auf einem echten OVN dieselben OVN-Zeilen und Statusaktualisierungen.
Ausführung
test/ovn/differential/record.py führt den Python-Treiber aus; TestDifferential spielt dieselben Schritte auf Go ab und vergleicht.
Letztes Ergebnis 35 / 35 Schritte identisch, abgesehen von einem bewussten Statusunterschied beim Health Monitor (2026-10-31).
Der OVN-Provider wird zu einem Go-Dienst, den die Octavia-API in neutron-api über HTTP aufruft, ohne Laden von Python-Treibern, Driver Agent oder Neutron-Sync-Plugin.
Vereinfachte interne Mechanik
Laden von Python-Providern und Driver Agent
Warum es ausgelassen wurde
neutron-api ist der einzige Aufrufer: Er ruft den Treiber über HTTP auf und empfängt die Statusmeldungen auf seinem Admin-Port statt über die Unix-Sockets des Driver Agents.
Warum die Lösung nicht beeinträchtigt ist
Load Balancer erreichen ACTIVE über die öffentliche Octavia-API. Ein kleiner Python-Shim existiert nur, um von einem Python-Octavia zu übernehmen.
Hier ist nur aufgeführt, was bewusst ausgelassen wurde; noch nicht erledigte Arbeit steht in den Known gaps der docs/CONFORMANCE.md des Moduls. Alle Module
Octavia (OVN)-Interaktionen
Dienstansicht, vom Diagramm-Skill aus dem OpenKeel-Modell generiert.