OpenKeel : la solution Cloud souveraine, française à portée européenne du groupe inherent Découvrir inherent
Composants · Réseau
Réseaux, sous-réseaux, ports, routeurs et groupes de sécurité écrits dans la base OVN Northbound ; IPv4 et 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)Extrait de openkeel-neutron/README.md (en anglais).
368 opérations de l'API REST d'origine (routes et actions de corps), et leur état dans OpenKeel.
Les échanges des tests unitaires ML2/OVN de Neutron Python et les échanges d'API d'Octavia sont rejoués contre le service Go ; les contrats avec Nova et OVN, la concurrence sur Galera et un vrai plan de données sont testés.
Les échanges enregistrés des tests unitaires ML2/OVN de Neutron Python donnent le même statut et le même corps depuis le service Go.
make e2e sur go-mysql-server, E2E_MYSQL_DSN pour MariaDB 11.4 ; E2E_STRICT=1 réussit avec test/e2e/known-differences.txt.
Dernier résultat 2344 / 2728 identiques (86 %, 2026-10-31) ; 2331 / 2728 sur MariaDB 11.4, avec les mêmes fichiers.
Source : openkeel-neutron/docs/CONFORMANCE.md
La liaison de port à un chassis OVN, le statut de port, network-vif-plugged et les autres événements, ainsi que l'API de liaison pour la migration à chaud, se comportent comme Nova l'attend.
TestNovaBootFlow dans internal/app ; types d'erreur client dans TestErrorTypes.
Dernier résultat Réussi.
Source : openkeel-neutron/docs/CONFORMANCE.md
L'allocation des VNI et des IP reste unique lorsque réseaux et ports sont créés simultanément par trois nœuds Galera.
make galera-test sur un cluster à 3 nœuds.
Dernier résultat Réussi : 20 réseaux pour 10 VNI donnent 10 créations avec des VNI distincts ; aucune adresse en double ; aucun 5xx ; chaque nœud lit les mêmes allocations.
Source : openkeel-neutron/docs/CONFORMANCE.md
Routeurs, SNAT, IP flottantes et répartition de charge fonctionnent pour de vrais invités sur OVN, avec isolation des projets.
openkeel-lab/scripts/dataplane-test.sh (78 vérifications) après un make lab-up PROFILE=dataplane à froid.
Dernier résultat Réussi (2026-11-01).
Source : openkeel-neutron/docs/CONFORMANCE.md
L'API Octavia v2 servie par neutron-api répond à l'identique aux échanges Octavia Python enregistrés, appels au provider compris.
make e2e-lbaas sur un nœud MariaDB Galera ; E2E_STRICT=1 échoue sur toute différence inexpliquée.
Dernier résultat 8 598 / 8 691 identiques ; appels au provider 3 826 / 3 831. Le rejeu propre à Python donne 8 683 / 8 691.
Source : openkeel-neutron/docs/CONFORMANCE.md
Les tests d'API Neutron amont contre le service déployé.
Pas encore dirigé vers le plan de données du lab.
Dernier résultat Non exécuté.
Source : openkeel-neutron/docs/CONFORMANCE.md
Neutron conserve son API cœur sur ML2/OVN et sert aussi l'API Octavia : les agents non OVN, le service Octavia séparé avec ses amphorae et les notifications inutilisées disparaissent.
Repris par OVN
OVN assure lui-même routage, DHCP, groupes de sécurité et NAT ; le driver de mécanisme ML2 est fixé à OVN, si bien que les agents L3, DHCP, OVS et Linux bridge et leurs assistants privsep sont inutiles.
L'API des agents ne liste que les chassis OVN Southbound ; PUT et DELETE sur les agents sont acquittés sans effet. Réseaux, routeurs et IP flottantes fonctionnent comme sur ML2/OVN.
Source : openkeel-neutron/docs/CONFORMANCE.md
Repris par Load balancers OVN
L'API Octavia v2 tourne dans le binaire neutron-api avec le provider OVN ; il n'y a pas de VM amphora, et la purge est une tâche périodique idempotente dans chaque réplique.
openstacksdk, le client openstack et octavia-tempest-plugin passent avec le provider OVN. Les routes amphora répondent comme une table vide.
Source : openkeel-neutron/docs/CONFORMANCE.md
Le provider OVN refuse de toute façon les listeners TLS : aucun gestionnaire de certificats n'est branché dans cette version.
Les requêtes de listener TLS sont validées, puis le provider répond 501. L'équilibrage TCP et UDP n'est pas concerné ; TLS peut se terminer dans les backends.
Source : openkeel-neutron/docs/CONFORMANCE.md
Le cœur d'OpenKeel n'a aucun consommateur de network.create.end et d'événements similaires, tel que Ceilometer.
Les ressources se comportent de la même façon ; les consommateurs de ces événements ne reçoivent rien de Neutron. Chaque appel d'API reste enregistré dans la piste d'audit CADF.
Source : openkeel-neutron/docs/CONFORMANCE.md
Seul ce qui a été écarté par choix de conception figure ici ; le travail pas encore fait se trouve dans les Known gaps du docs/CONFORMANCE.md du module. Tous les modules
Vue « service » générée par la skill diagramme depuis le modèle d'OpenKeel.
Plein écran| De | Vers | Protocole | Quoi |
|---|---|---|---|
| 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) |
Branche stable-2026.2 · 8 fichiers
Lire la reverse-specAPI Octavia v2 servie par neutron-api ; load balancers OVN, actifs par défaut.
Firewall groups, policies et rules (FWaaS v2).
VPN IPsec site à site : IKE, policies IPsec, connexions.
Annonce en BGP les IP de VMs et les IP flottantes joignables par le nœud.