OpenKeel: la solución Cloud soberana, francesa y de alcance europeo, del grupo inherent Descubrir inherent
Componentes · Redes
Redes, subredes, puertos, routers y grupos de seguridad escritos en la base de datos 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)Extracto de openkeel-neutron/README.md (en inglés).
368 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel.
Los intercambios de los tests unitarios ML2/OVN de Neutron en Python y los intercambios de API de Octavia se reproducen contra el servicio Go; se prueban los contratos con Nova y OVN, la concurrencia en Galera y un plano de datos real.
Los intercambios grabados de los tests unitarios ML2/OVN de Neutron en Python dan el mismo estado y el mismo cuerpo desde el servicio Go.
make e2e en go-mysql-server, E2E_MYSQL_DSN para MariaDB 11.4; E2E_STRICT=1 se supera con test/e2e/known-differences.txt.
Último resultado 2344 / 2728 idénticos (86 %, 2026-10-31); 2331 / 2728 en MariaDB 11.4, con los mismos archivos.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
La vinculación de puertos a un chassis OVN, el estado de los puertos, network-vif-plugged y otros eventos, así como la API de vinculación para la migración en vivo, se comportan como Nova espera.
TestNovaBootFlow en internal/app; tipos de error de cliente en TestErrorTypes.
Último resultado Superado.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
La asignación de VNI e IP sigue siendo única cuando se crean redes y puertos simultáneamente a través de tres nodos Galera.
make galera-test en un clúster de 3 nodos.
Último resultado Superado: 20 redes para 10 VNI dan 10 creadas con VNI distintos; ninguna dirección duplicada; ningún 5xx; cada nodo lee las mismas asignaciones.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
Los routers, SNAT, las IP flotantes y el balanceo de carga funcionan para instancias reales en OVN, con aislamiento entre proyectos.
openkeel-lab/scripts/dataplane-test.sh (78 comprobaciones) tras un make lab-up PROFILE=dataplane en frío.
Último resultado Superado (2026-11-01).
Fuente: openkeel-neutron/docs/CONFORMANCE.md
La API Octavia v2 servida por neutron-api responde de forma idéntica a los intercambios grabados de Octavia en Python, incluidas las llamadas al provider.
make e2e-lbaas en un nodo MariaDB Galera; E2E_STRICT=1 falla ante cualquier diferencia sin explicar.
Último resultado 8 598 / 8 691 idénticos; llamadas al provider 3 826 / 3 831. El replay propio de Python da 8 683 / 8 691.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
Los tests de API de Neutron upstream contra el servicio desplegado.
Aún no dirigido al plano de datos del laboratorio.
Último resultado No ejecutado.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
Neutron conserva su API principal sobre ML2/OVN y además sirve la API de Octavia, por lo que desaparecen los agentes no OVN, el servicio Octavia independiente con sus amphorae y las notificaciones sin uso.
Asumido por OVN
OVN se encarga por sí mismo del enrutamiento, DHCP, grupos de seguridad y NAT; el driver de mecanismo ML2 está fijado en OVN, por lo que no se necesitan los agentes L3, DHCP, OVS y Linux bridge ni sus asistentes privsep.
La API de agentes solo lista los chassis OVN Southbound; PUT y DELETE sobre agentes se confirman sin efecto. Redes, routers e IP flotantes funcionan como en ML2/OVN.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
Asumido por Load balancers de OVN
La API Octavia v2 se ejecuta en el binario neutron-api con el provider OVN; no hay VM amphora, y la purga es una tarea periódica idempotente en cada réplica.
openstacksdk, el cliente openstack y octavia-tempest-plugin pasan con el provider OVN. Las rutas amphora responden como una tabla vacía.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
El provider OVN rechaza de todos modos los listeners TLS, por lo que en esta versión no se conecta ningún gestor de certificados.
Las peticiones de listener TLS se validan y después el provider responde 501. El balanceo TCP y UDP no se ve afectado; TLS puede terminar en los backends.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
El núcleo de OpenKeel no tiene ningún consumidor de network.create.end ni de eventos similares, como Ceilometer.
Los recursos se comportan igual; los consumidores de estos eventos no reciben nada de Neutron. Cada llamada a la API sigue registrándose en el rastro de auditoría CADF.
Fuente: openkeel-neutron/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
Vista de servicio generada por la skill de diagramas a partir del modelo de OpenKeel.
Pantalla completa| De | A | Protocolo | Qué |
|---|---|---|---|
| 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 de 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) |
Rama stable-2026.2 · 8 archivos
Leer la reverse-specLa API Octavia v2 servida por neutron-api; load balancers de OVN, activados por defecto.
Grupos, políticas y reglas de firewall (FWaaS v2).
VPN IPsec site-to-site: IKE, políticas IPsec, conexiones.
Anuncia por BGP las IP de las VM y las IP flotantes accesibles a través del nodo.