OpenKeel: die souveräne französische Cloud-Lösung mit europäischer Reichweite der inherent-Gruppe inherent entdecken
Komponenten · Netzwerk
Netze, Subnetze, Ports, Router und Sicherheitsgruppen, in die OVN-Northbound-Datenbank geschrieben; IPv4 und 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)Auszug aus openkeel-neutron/README.md (auf Englisch).
368 Operationen der Original-REST-API (Routen und Body-Aktionen) und ihr Status in OpenKeel.
Die ML2/OVN-Unit-Test-Austausche von Python-Neutron und die API-Austausche von Octavia werden gegen den Go-Dienst wiedergegeben; Verträge mit Nova und OVN, Nebenläufigkeit auf Galera und eine echte Datenebene werden getestet.
Die aufgezeichneten Austausche der ML2/OVN-Unit-Tests von Python-Neutron liefern vom Go-Dienst denselben Status und Body.
make e2e auf go-mysql-server, E2E_MYSQL_DSN für MariaDB 11.4; E2E_STRICT=1 besteht mit test/e2e/known-differences.txt.
Letztes Ergebnis 2344 / 2728 identisch (86 %, 2026-10-31); 2331 / 2728 auf MariaDB 11.4, mit denselben Dateien.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Port-Binding an ein OVN-Chassis, Port-Status, network-vif-plugged und weitere Ereignisse sowie die Binding-API für die Live-Migration verhalten sich so, wie Nova es erwartet.
TestNovaBootFlow in internal/app; Client-Fehlertypen in TestErrorTypes.
Letztes Ergebnis Bestanden.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Die Vergabe von VNIs und IPs bleibt eindeutig, wenn Netze und Ports gleichzeitig über drei Galera-Knoten erstellt werden.
make galera-test auf einem Cluster mit 3 Knoten.
Letztes Ergebnis Bestanden: 20 Netze für 10 VNIs ergeben 10 erstellte mit unterschiedlichen VNIs; keine doppelte Adresse; kein 5xx; jeder Knoten liest dieselben Allokationen.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Router, SNAT, Floating IPs und Lastverteilung funktionieren für echte Gäste auf OVN, mit Projektisolation.
openkeel-lab/scripts/dataplane-test.sh (78 Prüfungen) nach einem Kaltstart mit make lab-up PROFILE=dataplane.
Letztes Ergebnis Bestanden (2026-11-01).
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Die von neutron-api bereitgestellte Octavia-v2-API beantwortet die aufgezeichneten Python-Octavia-Austausche identisch, einschließlich der Provider-Aufrufe.
make e2e-lbaas auf einem MariaDB-Galera-Knoten; E2E_STRICT=1 schlägt bei jedem unerklärten Unterschied fehl.
Letztes Ergebnis 8 598 / 8 691 identisch; Provider-Aufrufe 3 826 / 3 831. Pythons eigenes Replay erreicht 8 683 / 8 691.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Die Upstream-API-Tests von Neutron gegen den bereitgestellten Dienst.
Noch nicht auf die Datenebene des Labs ausgerichtet.
Letztes Ergebnis Nicht ausgeführt.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Neutron behält seine Kern-API auf ML2/OVN und stellt zusätzlich die Octavia-API bereit; damit entfallen Nicht-OVN-Agenten, der separate Octavia-Dienst mit seinen Amphorae und ungenutzte Benachrichtigungen.
Übernommen von OVN
OVN übernimmt Routing, DHCP, Sicherheitsgruppen und NAT selbst; der ML2-Mechanism-Treiber ist fest auf OVN gesetzt, sodass L3-, DHCP-, OVS- und Linux-Bridge-Agenten und ihre privsep-Helfer nicht benötigt werden.
Die Agents-API listet nur OVN-Southbound-Chassis auf; PUT und DELETE auf Agents werden ohne Wirkung bestätigt. Netzwerke, Router und Floating IPs funktionieren wie bei ML2/OVN.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Übernommen von OVN-Load-Balancer
Die Octavia-v2-API läuft im neutron-api-Binary mit dem OVN-Provider; es gibt keine amphora-VMs, und purge ist ein idempotenter periodischer Task in jeder Replik.
openstacksdk, der openstack-Client und octavia-tempest-plugin laufen mit dem OVN-Provider erfolgreich durch. Amphora-Routen antworten wie eine leere Tabelle.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Der OVN-Provider weist TLS-Listener ohnehin ab, daher ist in dieser Version kein Zertifikatsmanager angebunden.
Anfragen für TLS-Listener werden validiert und dann vom Provider mit 501 beantwortet. TCP- und UDP-Load-Balancing sind nicht betroffen; TLS kann in den Backends terminieren.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
Der Kern von OpenKeel hat keinen Konsumenten für network.create.end und ähnliche Ereignisse, etwa Ceilometer.
Ressourcen verhalten sich gleich; Konsumenten dieser Ereignisse erhalten nichts von Neutron. Jeder API-Aufruf wird weiterhin im CADF-Audit-Trail erfasst.
Quelle: openkeel-neutron/docs/CONFORMANCE.md
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
Dienstansicht, vom Diagramm-Skill aus dem OpenKeel-Modell generiert.
Vollbild| Von | Nach | Protokoll | Was |
|---|---|---|---|
| Skyline | Neutron server | REST-API | extensions, ports, FWaaS, VPN, load balancers |
| Nova API | Neutron server | REST-API | ports |
| Neutron server | Nova API | REST-API | network-vif-plugged |
| Neutron server | Neutron reconciler | SQL (MariaDB Galera) | reconciled from DB |
| Neutron reconciler | Kube-OVN | Kubernetes-API | Vpc, Subnet, IP, SecurityGroup, OvnFip |
| Ironic conductor | Neutron server | REST-API | provisioning/tenant ports |
| Heat engine | Neutron server | REST-API | OS::Neutron::* |
| EC2 API | Neutron server | REST-API | 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 | REST-API | proxy /v2.0/fwaas/*, same token |
| Neutron server | Neutron VPNaaS | REST-API | proxy /v2.0/vpn/*, vpn-agents, same token |
| Neutron VPNaaS | Neutron server | REST-API | core and L3 calls: gateway ports, routes |
| Neutron server | OVN Octavia provider | REST-API | Octavia driver API (:9877) |
| OVN Octavia provider | Neutron server | REST-API | /internal/lbaas status updates, ports, subnets |
| Zun compute | Neutron server | REST-API | ports bound to host (compute:zun) |
Branch stable-2026.2 · 8 Dateien
Reverse-Spec lesenDie Octavia-v2-API, bereitgestellt von neutron-api; OVN-Load-Balancer, standardmäßig aktiviert.
Firewall-Gruppen, -Policies und -Regeln (FWaaS v2).
Site-to-Site-IPsec-VPN: IKE, IPsec-Policies, Verbindungen.
Kündigt über BGP die VM- und Floating-IPs an, die über den Knoten erreichbar sind.