OpenKeel: la solución Cloud soberana, francesa y de alcance europeo, del grupo inherent Descubrir inherent

Componentes · Redes

Octavia (OVN)

La API Octavia v2 servida por neutron-api; load balancers de OVN, activados por defecto.

Go Load balancers de OVNopenkeel-ovn-octavia-provider

El módulo

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.

client ──/load-balancer/v2/lbaas──> neutron-api ──HTTP, bearer token──> ovn-octavia-provider ──OVSDB──> OVN NB, SB
                                        ^                                    │  │  └──REST──> Neutron, Keystone
                                        └──/internal/lbaas :9878, token──────┘  │
                                                                                └────events, maintenance (OVSDB lock neutron_ovn_octavia_event_lock)

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

Extracto de openkeel-ovn-octavia-provider/README.md (en inglés).

API REST

297 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel. Servido por neutron-api (openkeel-neutron, internal/lbaas).

  • 297Implementado

Cómo se prueba la compatibilidad

El provider en Go se ejecuta paso a paso junto al provider real de Python sobre el mismo OVN, y luego se verifica con octavia-tempest-plugin y tráfico real en el laboratorio.

Test diferencial

Comparación diferencial con el provider de Python

Los mismos 35 pasos producen las mismas filas OVN y actualizaciones de estado desde los providers de Python y Go sobre un OVN real.

Ejecución

test/ovn/differential/record.py ejecuta el driver de Python; TestDifferential reproduce los mismos pasos en Go y compara.

Último resultado 35 / 35 pasos idénticos, salvo una diferencia deliberada en el estado del health monitor (2026-10-31).

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Tests unitarios y golden tests

Tests unitarios y vectores

Los vectores de framing de VIP, los mensajes de rechazo con texto y estado exactos y la lógica del driver coinciden con el provider de Python.

Ejecución

go test ./... sobre un Northbound en memoria con el esquema real, también con -race.

Último resultado 96 superados, 0 fallidos (2026-11-01); vectores vips 57 / 57.

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Tests unitarios y golden tests

OVN real

Los flujos y las filas Service_Monitor producidos por ovn-northd, los eventos de monitor, el bloqueo y la sincronización se comportan según lo esperado.

Ejecución

make ovn-test contra OVN 25.03 (esquema 7.11.0).

Último resultado 6 superados.

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Tempest

octavia-tempest-plugin, provider ovn

Los tests de API y de escenario de Octavia upstream, con los ajustes del job OVN upstream, se superan a través de la API en neutron-api.

Ejecución

octavia-tempest-plugin con provider=ovn en el perfil de laboratorio dataplane, tokens reales de Keystone.

Último resultado API 82 superados, 0 fallidos; escenario 22 superados, 0 fallidos (2026-11-01). Tests de tráfico (56) no ejecutados.

Fuente: openkeel-neutron/docs/CONFORMANCE.md

De extremo a extremo en un laboratorio

Tráfico real con instancias reales

VIP accesibles desde otra subred y a través de una IP flotante, miembros con IP flotantes, comprobaciones de salud de OVN que retiran una instancia detenida.

Ejecución

openkeel-lab/scripts/dataplane-test.sh (78 comprobaciones) con el Neutron en Go.

Último resultado Superado (2026-11-01).

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Contrato de cliente

Shim en un octavia-api real

La vía de toma de control: el provider en Go detrás de un octavia-api de Python real y un driver agent.

Ejecución

El framing del socket solo se ha probado contra un sustituto.

Último resultado No ejecutado.

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Excluido del rewrite

El provider OVN pasa a ser un servicio Go al que la API de Octavia en neutron-api llama por HTTP, sin carga de drivers Python, sin driver agent ni plugin de sincronización de Neutron.

Mecánica interna simplificada

Carga de providers Python y driver agent

Por qué se excluyó

neutron-api es el único llamante: llama al driver por HTTP y recibe los mensajes de estado en su puerto de administración en lugar de en los sockets Unix del driver agent.

Por qué la solución no se ve afectada

Los load balancers alcanzan ACTIVE a través de la API pública de Octavia. Un pequeño shim de Python existe solo para tomar el relevo de un Octavia en Python.

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Mecánica interna simplificada

Plugin de Octavia de neutron-ovn-db-sync-util

Por qué se excluyó

El plugin pertenece a la herramienta Python de Neutron, que OpenKeel no incluye.

Por qué la solución no se ve afectada

octavia-ovn-db-sync-util cubre la reparación de las filas de load balancer de OVN.

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Obsoleto o sin uso en upstream

Opciones de endpoint de keystoneauth obsoletas

Por qué se excluyó

endpoint, endpoint_type y ca_certificates_file están obsoletos en upstream; service_auth con archivos de secretos los sustituye.

Por qué la solución no se ve afectada

Solo configuración; el provider llega a Neutron de la misma manera.

Fuente: openkeel-ovn-octavia-provider/docs/CONFORMANCE.md

Aquí solo figura lo que se excluyó por diseño; el trabajo aún no realizado está en los Known gaps del docs/CONFORMANCE.md del módulo. Todos los módulos

Interacciones Octavia (OVN)

Vista de servicio generada por la skill de diagramas a partir del modelo de OpenKeel.

Diagrama openkeel-ovn-octavia-provider.svg Pantalla completa
Las 5 interacciones del modelo
DeAProtocoloQué
Neutron serverOVN Octavia providerAPI RESTOctavia driver API (:9877)
OVN Octavia providerNeutron serverAPI REST/internal/lbaas status updates, ports, subnets
OVN Octavia providerKeystoneAPI RESTservice token
OVN Octavia providerOVN Northbound DBOVSDBLoad_Balancer rows; events, maintenance (OVSDB lock)
OVN Octavia providerOVN Southbound DBOVSDBreads chassis, port bindings

Especificaciones