OpenKeel: la soluzione Cloud sovrana, francese e di portata europea, del gruppo inherent Scopri inherent
Componenti · Rete
Reti, subnet, porte, router e gruppi di sicurezza scritti nel database OVN Northbound; IPv4 e IPv6.
OpenKeel implementation in Go of OpenStack neutron (neutron-api), generated from the reverse-specification of branch stable/2026.2 by the generate-go-from-spec skill. Scope: the Neutron core on ML2/OVN — networks, subnets (internal IPAM), ports with ML2 port binding and the binding-extended API used by Nova for live migration, security groups, routers (interfaces, gateway, extra routes) and floating IPs, plus quotas, tags, agents and availability zones read from the OVN Southbound database. Extensions (QoS, trunks, segments API, port forwarding, VPNaaS, BGP…) come later; their collections answer empty lists.
neutron-api also serves the Octavia v2 API (internal/lbaas, under /load-balancer): Python Octavia does not run, and openkeel-ovn-octavia-provider stays a separate service, the only back end. Design, seam and differences: docs/OCTAVIA.md.
The backend is a parallel OVN owned by Neutron (references/backends/neutron-ovn.md, design B): the service writes the OVN Northbound rows exactly as Python's ML2/OVN driver does — same tables, names, external_ids keys and options — because ovn-bgp-agent, ovn-octavia-provider and the OVN metadata agent stay in Python and read them. It turns Logical_Switch_Port.up into port status changes and sends Nova the network-vif-plugged / network-vif-unplugged / network-vif-deleted / network-changed external events.
It replaces the Python service without its clients noticing: same routes, status codes, NeutronError bodies and types, policies. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md.
github.com/openkeel/openkeel-neutronneutron-api (API on port 9696, health and metrics on 9090)Estratto da openkeel-neutron/README.md (in inglese).
368 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel.
Gli scambi dei test unitari ML2/OVN di Neutron Python e gli scambi API di Octavia vengono riprodotti sul servizio Go; vengono testati i contratti con Nova e OVN, la concorrenza su Galera e un data plane reale.
Gli scambi registrati dei test unitari ML2/OVN di Neutron Python restituiscono lo stesso stato e lo stesso corpo dal servizio Go.
make e2e su go-mysql-server, E2E_MYSQL_DSN per MariaDB 11.4; E2E_STRICT=1 superato con test/e2e/known-differences.txt.
Ultimo risultato 2344 / 2728 identici (86 %, 2026-10-31); 2331 / 2728 su MariaDB 11.4, con gli stessi file.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
Il binding delle porte a uno chassis OVN, lo stato delle porte, network-vif-plugged e gli altri eventi, nonché l'API di binding per la migrazione a caldo, si comportano come Nova si aspetta.
TestNovaBootFlow in internal/app; tipi di errore client in TestErrorTypes.
Ultimo risultato Superato.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
L'allocazione di VNI e IP resta univoca quando reti e porte vengono create contemporaneamente da tre nodi Galera.
make galera-test su un cluster a 3 nodi.
Ultimo risultato Superato: 20 reti per 10 VNI danno 10 create con VNI distinti; nessun indirizzo duplicato; nessun 5xx; ogni nodo legge le stesse allocazioni.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
Router, SNAT, IP flottanti e bilanciamento del carico funzionano per istanze guest reali su OVN, con isolamento tra progetti.
openkeel-lab/scripts/dataplane-test.sh (78 controlli) dopo un make lab-up PROFILE=dataplane a freddo.
Ultimo risultato Superato (2026-11-01).
Fonte: openkeel-neutron/docs/CONFORMANCE.md
L'API Octavia v2 servita da neutron-api risponde in modo identico agli scambi registrati di Octavia Python, chiamate al provider incluse.
make e2e-lbaas su un nodo MariaDB Galera; E2E_STRICT=1 fallisce su qualsiasi differenza inspiegata.
Ultimo risultato 8 598 / 8 691 identici; chiamate al provider 3 826 / 3 831. Il replay di Python stesso dà 8 683 / 8 691.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
I test API di Neutron upstream sul servizio distribuito.
Non ancora puntato al data plane del laboratorio.
Ultimo risultato Non eseguito.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
Neutron mantiene la sua API principale su ML2/OVN e serve anche l'API Octavia, per cui scompaiono gli agenti non OVN, il servizio Octavia separato con le sue amphorae e le notifiche inutilizzate.
Gestito da OVN
OVN gestisce da sé routing, DHCP, security group e NAT; il mechanism driver ML2 è fissato su OVN, per cui gli agenti L3, DHCP, OVS e Linux bridge e i loro helper privsep non servono.
L'API degli agenti elenca solo gli chassis OVN Southbound; PUT e DELETE sugli agenti vengono confermati senza effetto. Reti, router e IP flottanti funzionano come su ML2/OVN.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
Gestito da Load balancer OVN
L'API Octavia v2 gira nel binario neutron-api con il provider OVN; non ci sono VM amphora, e la purge è un task periodico idempotente in ogni replica.
openstacksdk, il client openstack e octavia-tempest-plugin passano con il provider OVN. Le route amphora rispondono come una tabella vuota.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
Il provider OVN rifiuta comunque i listener TLS, quindi in questa versione non è collegato alcun certificate manager.
Le richieste di listener TLS vengono validate, poi il provider risponde 501. Il bilanciamento TCP e UDP non è interessato; TLS può terminare nei backend.
Fonte: openkeel-neutron/docs/CONFORMANCE.md
Il nucleo di OpenKeel non ha consumatori di network.create.end e di eventi simili, come Ceilometer.
Le risorse si comportano allo stesso modo; i consumatori di questi eventi non ricevono nulla da Neutron. Ogni chiamata API resta registrata nell'audit trail CADF.
Fonte: openkeel-neutron/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
Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.
Schermo intero| Da | A | Protocollo | Cosa |
|---|---|---|---|
| Skyline | Neutron server | API REST | extensions, ports, FWaaS, VPN, load balancers |
| Nova API | Neutron server | API REST | ports |
| Neutron server | Nova API | API REST | network-vif-plugged |
| Neutron server | Neutron reconciler | SQL (MariaDB Galera) | reconciled from DB |
| Neutron reconciler | Kube-OVN | API Kubernetes | Vpc, Subnet, IP, SecurityGroup, OvnFip |
| Ironic conductor | Neutron server | API REST | provisioning/tenant ports |
| Heat engine | Neutron server | API REST | OS::Neutron::* |
| EC2 API | Neutron server | API REST | VPC, subnets, security groups |
| Neutron server | OVN Northbound DB | OVSDB | NB writes: switches, ports, routers, ACLs, NAT, DHCP; LSP.up monitor |
| Neutron server | OVN Southbound DB | OVSDB | SB reads: Chassis, Chassis_Private (liveness, binding) |
| Neutron reconciler | OVN Northbound DB | OVSDB | repairs drift (maintenance loop) |
| Neutron server | Neutron FWaaS | API REST | proxy /v2.0/fwaas/*, same token |
| Neutron server | Neutron VPNaaS | API REST | proxy /v2.0/vpn/*, vpn-agents, same token |
| Neutron VPNaaS | Neutron server | API REST | core and L3 calls: gateway ports, routes |
| Neutron server | OVN Octavia provider | API REST | Octavia driver API (:9877) |
| OVN Octavia provider | Neutron server | API REST | /internal/lbaas status updates, ports, subnets |
| Zun compute | Neutron server | API REST | ports bound to host (compute:zun) |
Branch stable-2026.2 · 8 file
Leggi la reverse-specL'API Octavia v2 servita da neutron-api; load balancer OVN, attivati per impostazione predefinita.
Gruppi, policy e regole di firewall (FWaaS v2).
VPN IPsec site-to-site: IKE, policy IPsec, connessioni.
Annuncia tramite BGP gli IP delle VM e gli IP flottanti raggiungibili attraverso il nodo.