OpenKeel: la soluzione Cloud sovrana, francese e di portata europea, del gruppo inherent Scopri inherent

Componenti · Rete

Octavia (OVN)

L'API Octavia v2 servita da neutron-api; load balancer OVN, attivati per impostazione predefinita.

Go Load balancer OVNopenkeel-ovn-octavia-provider

Il modulo

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

Estratto da openkeel-ovn-octavia-provider/README.md (in inglese).

API REST

297 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel. Servito da neutron-api (openkeel-neutron, internal/lbaas).

  • 297Implementato

Come viene testata la compatibilità

Il provider Go viene eseguito passo per passo accanto al vero provider Python sullo stesso OVN, quindi verificato con octavia-tempest-plugin e traffico reale sul laboratorio.

Test differenziale

Confronto differenziale con il provider Python

Gli stessi 35 passi producono le stesse righe OVN e gli stessi aggiornamenti di stato dai provider Python e Go su un OVN reale.

Esecuzione

test/ovn/differential/record.py esegue il driver Python; TestDifferential esegue gli stessi passi su Go e confronta.

Ultimo risultato 35 / 35 passi identici, salvo una differenza deliberata nello stato dell'health monitor (2026-10-31).

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

Test unitari e golden test

Test unitari e vettori

I vettori di framing VIP, i messaggi di rifiuto con testo e stato esatti e la logica del driver corrispondono al provider Python.

Esecuzione

go test ./... su un Northbound in memoria con lo schema reale, anche con -race.

Ultimo risultato 96 superati, 0 falliti (2026-11-01); vettori vips 57 / 57.

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

Test unitari e golden test

OVN reale

I flussi e le righe Service_Monitor prodotti da ovn-northd, gli eventi di monitor, il lock e la sincronizzazione si comportano come previsto.

Esecuzione

make ovn-test su OVN 25.03 (schema 7.11.0).

Ultimo risultato 6 superati.

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

Tempest

octavia-tempest-plugin, provider ovn

I test API e di scenario di Octavia upstream, con le impostazioni del job OVN upstream, vengono superati tramite l'API in neutron-api.

Esecuzione

octavia-tempest-plugin con provider=ovn sul profilo di laboratorio dataplane, token Keystone reali.

Ultimo risultato API 82 superati, 0 falliti; scenario 22 superati, 0 falliti (2026-11-01). Test di traffico (56) non eseguiti.

Fonte: openkeel-neutron/docs/CONFORMANCE.md

End-to-end su un laboratorio

Traffico reale con istanze guest reali

VIP raggiungibili da un'altra subnet e tramite un IP flottante, member con IP flottanti, health check OVN che rimuovono un'istanza guest arrestata.

Esecuzione

openkeel-lab/scripts/dataplane-test.sh (78 controlli) con il Neutron Go.

Ultimo risultato Superato (2026-11-01).

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

Contratto client

Shim in un octavia-api reale

Il percorso di presa in carico: il provider Go dietro un vero octavia-api Python e un driver agent.

Esecuzione

Il framing del socket è stato testato solo con un sostituto.

Ultimo risultato Non eseguito.

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

Escluso dal rewrite

Il provider OVN diventa un servizio Go chiamato via HTTP dall'API Octavia in neutron-api, senza caricamento di driver Python, driver agent o plugin di sincronizzazione Neutron.

Meccanismi interni semplificati

Caricamento dei provider Python e driver agent

Perché è stato escluso

neutron-api è l'unico chiamante: chiama il driver via HTTP e riceve i messaggi di stato sulla sua porta di amministrazione anziché sui socket Unix del driver agent.

Perché la soluzione non ne risente

I load balancer raggiungono ACTIVE tramite l'API pubblica di Octavia. Un piccolo shim Python esiste solo per subentrare a un Octavia Python.

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

Meccanismi interni semplificati

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

Perché è stato escluso

Il plugin appartiene allo strumento Python di Neutron, che OpenKeel non distribuisce.

Perché la soluzione non ne risente

octavia-ovn-db-sync-util copre la riparazione delle righe dei load balancer OVN.

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

Obsoleto o inutilizzato upstream

Opzioni di endpoint keystoneauth deprecate

Perché è stato escluso

endpoint, endpoint_type e ca_certificates_file sono deprecati upstream; service_auth con file di secret li sostituisce.

Perché la soluzione non ne risente

Solo configurazione; il provider raggiunge Neutron allo stesso modo.

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

Qui è elencato solo ciò che è stato escluso per scelta progettuale; il lavoro non ancora svolto si trova nei Known gaps del docs/CONFORMANCE.md del modulo. Tutti i moduli

Interazioni Octavia (OVN)

Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.

Diagramma openkeel-ovn-octavia-provider.svg Schermo intero
Le 5 interazioni del modello
DaAProtocolloCosa
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

Specifiche