OpenKeel: la soluzione Cloud sovrana, francese e di portata europea, del gruppo inherent Scopri inherent
Componenti · Calcolo e capacità
Inventari delle risorse e allocazioni; il primo componente riscritto in 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)Estratto da openkeel-placement/README.md (in inglese).
37 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel.
Gli scambi gabbi registrati di Placement Python vengono riprodotti sul servizio Go, e la suite funzionale di Nova stessa viene eseguita con il servizio Go al posto di Placement Python.
Ogni richiesta dei 79 file gabbi upstream restituisce lo stesso stato e lo stesso corpo del servizio Python registrato.
make e2e, con E2E_MYSQL_DSN per MariaDB; report in test/e2e/report.json, differenze elencate in known-differences.txt.
Ultimo risultato 1303 / 1316 identici su MariaDB 11.4 (1301 / 1316 su go-mysql-server); nessuna delle differenze residue è un bug funzionale.
Fonte: openkeel-placement/docs/CONFORMANCE.md
L'algoritmo allocation-candidates restituisce gli stessi candidati di Python su 83 casi registrati, fino a 6000 provider.
go test -tags e2e -run TestAllocationCandidateCases ./test/e2e/; report in test/e2e/cases-report.json.
Ultimo risultato 81 / 83 identici, 83 / 83 sul numero di candidati.
Fonte: openkeel-placement/docs/CONFORMANCE.md
La suite di test funzionali di Nova viene superata quando ogni chiamata a Placement è servita dal servizio Go invece che da Placement Python.
I test funzionali di Nova vengono eseguiti tramite test/nova-functional/run.sh, su go-mysql-server e MariaDB 11.4, a confronto con un riferimento Placement Python.
Ultimo risultato Sottoinsieme 859 / 859 su MariaDB 11.4 (come Python); suite completa 3314 superati, 1 fallito (un bug del motore) su go-mysql-server (2026-10-28).
Fonte: openkeel-placement/docs/NOVA-FUNCTIONAL.md
Allocazioni concorrenti tramite tre istanze del servizio su tre nodi Galera non sovrallocano mai un resource provider.
GALERA_DSNS=... go test -tags galera ./test/galera/ su un cluster MariaDB Galera 11.4 a 3 nodi.
Ultimo risultato Superato: 180 allocazioni concorrenti per 100 VCPU danno esattamente 100 allocazioni, 0 stati imprevisti.
Fonte: openkeel-placement/docs/CONFORMANCE.md
Tempest e test funzionali di Nova su un Placement distribuito in un cluster.
Richiede un cluster kind (reverse-spec 07 § 7 passo 5).
Ultimo risultato Non eseguito.
Fonte: openkeel-placement/docs/CONFORMANCE.md
Placement mantiene tutta la sua API e tralascia solo la modalità di test non autenticata, le vecchie migrazioni dei dati e l'infrastruttura di servizio oslo che Kubernetes fornisce già.
Un'API senza autenticazione non ha posto in produzione; le suite di test iniettano invece un validatore di token.
I client si autenticano sempre tramite Keystone, come in qualsiasi deployment reale. Nova, Neutron e osc-placement non sono interessati.
Fonte: openkeel-placement/docs/CONFORMANCE.md
set_root_provider_ids e create_incomplete_consumers correggono solo database precedenti al branch riprodotto.
Un database nuovo o aggiornato non ne ha mai bisogno; i database precedenti al branch vengono rifiutati anziché migrati sul posto.
Fonte: openkeel-placement/docs/CONFORMANCE.md
Gestito da Ingress (Gateway API)
Gli header cross-origin riguardano l'edge HTTP, non ogni singolo processo API.
Nessun client OpenKeel chiama Placement da un browser su un'altra origine; dove necessario, CORS si configura una sola volta sull'ingress.
Fonte: openkeel-placement/docs/CONFORMANCE.md
Gestito da Kubernetes probes, OpenTelemetry
I log vanno su stdout in JSON, le tracce a OpenTelemetry e lo stato di salute alle probes Kubernetes; 101 delle 108 opzioni oslo sono diventate inutili.
Gli operatori ottengono le stesse informazioni tramite gli strumenti di log, tracing e probe del cluster; l'API resta invariata.
Fonte: openkeel-placement/config/dropped-options.md
Qui è elencato solo ciò che è stato escluso per scelta progettuale; il lavoro non ancora svolto si trova nei Known gaps del docs/CONFORMANCE.md del modulo. Tutti i moduli
Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.
Schermo intero| Da | A | Protocollo | Cosa |
|---|---|---|---|
| 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) |
Branch stable-2026.2 · 9 file
Leggi la reverse-specBranch stable-2026.2 · 9 file
Leggi la reverse-specLe istanze girano come VirtualMachine KubeVirt; conductor con lo scheduler integrato nel processo, un agente per nodo.
Containers as a Service: un Pod per container, isolato nella propria microVM Kata, con la sua porta Neutron come unica rete.
Alta disponibilità delle istanze; stato dei nodi tramite Node Healthcheck e Self Node Remediation.
Bare metal: resta Python upstream, impacchettato in un chart OpenKeel; troppe configurazioni hardware da testare.