OpenKeel: la solución Cloud soberana, francesa y de alcance europeo, del grupo inherent Descubrir inherent
Componentes · Cómputo y capacidad
Inventarios de recursos y asignaciones; el primer componente reescrito en Go.
OpenKeel implementation in Go of OpenStack placement (placement-api), generated from the reverse-specification of branch stable/2026.2 by the generate-go-from-spec skill. It replaces the Python service without its clients noticing: same routes, status codes, error bodies, microversions and policies. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md.
github.com/openkeel/openkeel-placementplacement-api (API on port 8778, health and metrics on 9090)Extracto de openkeel-placement/README.md (en inglés).
37 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel.
Los intercambios gabbi grabados de Placement en Python se reproducen contra el servicio Go, y la propia suite funcional de Nova se ejecuta con el servicio Go en lugar de Placement en Python.
Cada petición de los 79 archivos gabbi upstream da el mismo estado y el mismo cuerpo que el servicio Python grabado.
make e2e, con E2E_MYSQL_DSN para MariaDB; informe en test/e2e/report.json, diferencias enumeradas en known-differences.txt.
Último resultado 1303 / 1316 idénticos en MariaDB 11.4 (1301 / 1316 en go-mysql-server); ninguna de las diferencias restantes es un error funcional.
Fuente: openkeel-placement/docs/CONFORMANCE.md
El algoritmo allocation-candidates devuelve los mismos candidatos que Python en 83 casos grabados, con hasta 6000 providers.
go test -tags e2e -run TestAllocationCandidateCases ./test/e2e/; informe en test/e2e/cases-report.json.
Último resultado 81 / 83 idénticos, 83 / 83 en el número de candidatos.
Fuente: openkeel-placement/docs/CONFORMANCE.md
La suite de tests funcionales de Nova se supera cuando cada llamada a Placement la sirve el servicio Go en lugar de Placement en Python.
Los tests funcionales de Nova se ejecutan mediante test/nova-functional/run.sh, en go-mysql-server y MariaDB 11.4, comparados con una referencia de Placement en Python.
Último resultado Subconjunto 859 / 859 en MariaDB 11.4 (como Python); suite completa 3314 superados, 1 fallido (un error del motor) en go-mysql-server (2026-10-28).
Fuente: openkeel-placement/docs/NOVA-FUNCTIONAL.md
Las asignaciones concurrentes a través de tres instancias del servicio en tres nodos Galera nunca sobreasignan un resource provider.
GALERA_DSNS=... go test -tags galera ./test/galera/ en un clúster MariaDB Galera 11.4 de 3 nodos.
Último resultado Superado: 180 asignaciones concurrentes para 100 VCPU dan exactamente 100 asignaciones, 0 estados inesperados.
Fuente: openkeel-placement/docs/CONFORMANCE.md
Tempest y tests funcionales de Nova contra un Placement desplegado en un clúster.
Requiere un clúster kind (reverse-spec 07 § 7 paso 5).
Último resultado No ejecutado.
Fuente: openkeel-placement/docs/CONFORMANCE.md
Placement conserva toda su API y solo prescinde del modo de prueba sin autenticación, las antiguas migraciones de datos y la infraestructura de servicio oslo que Kubernetes ya proporciona.
Una API sin autenticación no tiene cabida en producción; las suites de pruebas inyectan en su lugar un validador de tokens.
Los clientes siempre se autentican a través de Keystone, como en cualquier despliegue real. Nova, Neutron y osc-placement no se ven afectados.
Fuente: openkeel-placement/docs/CONFORMANCE.md
set_root_provider_ids y create_incomplete_consumers solo corrigen bases de datos anteriores a la rama reproducida.
Una base de datos nueva o actualizada nunca las necesita; las bases de datos anteriores a la rama se rechazan en lugar de migrarse in situ.
Fuente: openkeel-placement/docs/CONFORMANCE.md
Asumido por Ingress (Gateway API)
Las cabeceras cross-origin corresponden al borde HTTP, no a cada proceso de API.
Ningún cliente de OpenKeel llama a Placement desde un navegador en otro origen; cuando es necesario, CORS se configura una sola vez en el ingress.
Fuente: openkeel-placement/docs/CONFORMANCE.md
Asumido por Kubernetes probes, OpenTelemetry
Los logs van a stdout en JSON, las trazas a OpenTelemetry y el estado de salud a las probes de Kubernetes; 101 de las 108 opciones oslo dejaron de ser útiles.
Los operadores obtienen la misma información con las herramientas de logs, trazas y probes del clúster; la API no cambia.
Fuente: openkeel-placement/config/dropped-options.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é |
|---|---|---|---|
| Nova API | Placement | API REST | usages, quotas |
| Nova conductor + scheduler | Placement | API REST | allocation candidates, claims |
| Nova compute agent | Placement | API REST | inventory, traits |
| Zun API | Placement | API REST | allocation candidates, claims |
| Zun compute agent | Placement | API REST | inventory (Node UID provider) |
Rama stable-2026.2 · 9 archivos
Leer la reverse-specRama stable-2026.2 · 9 archivos
Leer la reverse-specLas instancias se ejecutan como VirtualMachines de KubeVirt; conductor con el scheduler integrado en el proceso, un agente por nodo.
Containers as a Service: un Pod por contenedor, aislado en su propia microVM Kata, con su puerto Neutron como única red.
Alta disponibilidad de instancias; estado de los nodos mediante Node Healthcheck y Self Node Remediation.
Bare metal: sigue siendo Python upstream, empaquetado en un chart de OpenKeel; demasiadas configuraciones de hardware que probar.