OpenKeel : la solution Cloud souveraine, française à portée européenne du groupe inherent Découvrir inherent
Composants · Calcul et capacités
Inventaires et allocations de ressources ; premier composant réécrit 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)Extrait de openkeel-placement/README.md (en anglais).
37 opérations de l'API REST d'origine (routes et actions de corps), et leur état dans OpenKeel.
Les échanges gabbi enregistrés de Placement Python sont rejoués contre le service Go, et la propre suite fonctionnelle de Nova s'exécute avec le service Go à la place de Placement Python.
Chaque requête des 79 fichiers gabbi amont donne le même statut et le même corps que le service Python enregistré.
make e2e, avec E2E_MYSQL_DSN pour MariaDB ; rapport dans test/e2e/report.json, différences listées dans known-differences.txt.
Dernier résultat 1303 / 1316 identiques sur MariaDB 11.4 (1301 / 1316 sur go-mysql-server) ; aucune des différences restantes n'est un bogue fonctionnel.
Source : openkeel-placement/docs/CONFORMANCE.md
L'algorithme allocation-candidates renvoie les mêmes candidats que Python sur 83 cas enregistrés, jusqu'à 6000 providers.
go test -tags e2e -run TestAllocationCandidateCases ./test/e2e/ ; rapport dans test/e2e/cases-report.json.
Dernier résultat 81 / 83 identiques, 83 / 83 sur le nombre de candidats.
Source : openkeel-placement/docs/CONFORMANCE.md
La suite de tests fonctionnels de Nova réussit lorsque chaque appel à Placement est servi par le service Go au lieu de Placement Python.
Les tests fonctionnels de Nova s'exécutent via test/nova-functional/run.sh, sur go-mysql-server et MariaDB 11.4, comparés à une référence Placement Python.
Dernier résultat Sous-ensemble 859 / 859 sur MariaDB 11.4 (comme Python) ; suite complète 3314 réussis, 1 échec (un bogue du moteur) sur go-mysql-server (2026-10-28).
Source : openkeel-placement/docs/NOVA-FUNCTIONAL.md
Des allocations concurrentes via trois instances du service sur trois nœuds Galera ne surallouent jamais un resource provider.
GALERA_DSNS=... go test -tags galera ./test/galera/ sur un cluster MariaDB Galera 11.4 à 3 nœuds.
Dernier résultat Réussi : 180 allocations concurrentes pour 100 VCPU donnent exactement 100 allocations, 0 statut inattendu.
Source : openkeel-placement/docs/CONFORMANCE.md
Tempest et tests fonctionnels de Nova contre un Placement déployé sur un cluster.
Nécessite un cluster kind (reverse-spec 07 § 7 étape 5).
Dernier résultat Non exécuté.
Source : openkeel-placement/docs/CONFORMANCE.md
Placement conserve toute son API et ne laisse de côté que le mode de test non authentifié, les anciennes migrations de données et la plomberie de service oslo que Kubernetes fournit déjà.
Une API sans authentification n'a pas sa place en production ; les suites de tests injectent plutôt un validateur de jetons.
Les clients s'authentifient toujours via Keystone, comme dans tout déploiement réel. Nova, Neutron et osc-placement ne sont pas concernés.
Source : openkeel-placement/docs/CONFORMANCE.md
set_root_provider_ids et create_incomplete_consumers ne corrigent que les bases antérieures à la branche reproduite.
Une base neuve ou à jour n'en a jamais besoin ; les bases antérieures à la branche sont refusées au lieu d'être migrées sur place.
Source : openkeel-placement/docs/CONFORMANCE.md
Repris par Ingress (Gateway API)
Les en-têtes cross-origin relèvent de la périphérie HTTP, pas de chaque processus d'API.
Aucun client OpenKeel n'appelle Placement depuis un navigateur sur une autre origine ; si besoin, CORS se configure une fois sur l'ingress.
Source : openkeel-placement/docs/CONFORMANCE.md
Repris par Kubernetes probes, OpenTelemetry
Les logs partent sur stdout en JSON, les traces vers OpenTelemetry et la santé vers les probes Kubernetes ; 101 des 108 options oslo sont devenues inutiles.
Les opérateurs obtiennent les mêmes informations via les outils de logs, de traçage et de probes du cluster ; l'API est inchangée.
Source : openkeel-placement/config/dropped-options.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 |
|---|---|---|---|
| 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) |
Branche stable-2026.2 · 9 fichiers
Lire la reverse-specBranche stable-2026.2 · 9 fichiers
Lire la reverse-specInstances exécutées comme VirtualMachines KubeVirt ; conductor avec le scheduler intégré, un agent par nœud.
Containers as a Service : un Pod par conteneur, isolé dans sa microVM Kata, avec son port Neutron comme seul réseau.
Haute disponibilité des instances ; santé des nœuds par Node Healthcheck et Self Node Remediation.
Bare metal : reste en Python amont, empaqueté dans un chart OpenKeel ; trop de configurations matérielles à tester.