Componenti · Calcolo e capacità

Masakari

Alta disponibilità delle istanze; stato dei nodi tramite Node Healthcheck e Self Node Remediation.

Go Medik8sopenkeel-masakari

Il modulo

OpenKeel implementation in Go of OpenStack Masakari, the instance high-availability service (masakari-api, masakari-engine, masakari-manage), 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.

Go module: github.com/openkeel/openkeel-masakari
Binaries (one image):
- masakari-api: the instance-ha API v1, microversions 1.0–1.3 (port 15868; health and metrics on 9090);
- masakari-engine: claims new notifications and runs the recovery workflows (host evacuation by segment recovery method, instance restart, compute-service disable) through Nova (openkeel-nova), runs the periodic tasks on the Lease holder and, in a cluster, the Medik8s/KubeVirt integration below;
- masakari-manage: db sync, db version, db purge.
Kubernetes-native HA (internal/kube, [references/backends/masakari-kubevirt.md] of the skill and openkeel-docs/NODE-PLACEMENT.md § 5.6 of the workspace): one Medik8s NodeHealthCheck per segment detects and fences failed nodes (Self Node Remediation, OutOfServiceTaint); the engine reports the host failure only once the node is fenced and evacuates its VMs per segment policy; it live-migrates the VMs of degraded or drained nodes before they fail, and mirrors segments and reserved hosts on node labels and taints.
Configuration: YAML, see config/config.example.yaml
Setting up a development environment, the database and the tests: docs/GETTING-STARTED.md
Database schema, migrations and upgrades: docs/DATABASE.md

Estratto da openkeel-masakari/README.md (in inglese).

API REST

21 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel.

21Implementato

Vedi tutte le operazioni

Come viene testata la compatibilità

Gli scenari registrati di Masakari Python vengono riprodotti sul servizio Go, il motore di recupero viene confrontato con le chiamate a Nova effettuate da Python e la concorrenza viene testata su Galera.

Replay degli scambi registrati

Replay E2E degli scenari registrati

I 201 scambi di 23 scenari ordinati, con lo stesso Nova simulato e gli stessi task periodici, restituiscono le stesse risposte di Python.

Esecuzione

make e2e, su go-mysql-server e su MariaDB 11.4 (E2E_MYSQL_DSN); make e2e-strict superato.

Ultimo risultato 195 / 201 su entrambi i motori; 6 differenze deliberate elencate in test/e2e/known-differences.txt.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Contratto client

Motore a confronto con le chiamate Nova registrate

I flussi di recupero di host e istanze inviano a Nova le stesse modifiche, per server, servizio e aggregato, del motore Python.

Esecuzione

internal/engine/engine_test.go su nova-calls_stable-2026.2.json (143 richieste).

Ultimo risultato Modifiche identiche per server, servizio e aggregato; i conteggi del polling GET non vengono confrontati.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Test unitari e golden test

Test unitari e di policy

Il routing dell'API, le microversioni, i messaggi di validazione e le 24 regole di policy per due personas si comportano come in Python.

Esecuzione

make test, con simulatori client-go per l'integrazione con Kubernetes.

Ultimo risultato Superato.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Concorrenza su Galera

Concorrenza su MariaDB Galera

Nomi univoci e notifiche duplicate reggono su tre nodi, e motori su tre nodi evacuano un host una sola volta.

Esecuzione

make galera-test su un cluster a 3 nodi.

Ultimo risultato Superato: segmenti e host con lo stesso nome 1 × 201, 17 × 409; notifiche duplicate 1 × 202, 23 × 409.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Tempest

Test funzionali su un cluster distribuito

Test funzionali di Masakari (openstacksdk) e test in stile Tempest su un servizio distribuito.

Esecuzione

Richiedono un cluster distribuito.

Ultimo risultato Non eseguito.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Escluso dal rewrite

Masakari mantiene la sua API e i workflow di ripristino ma rileva i guasti degli host con Medik8s anziché con masakari-monitors, e sostituisce RPC, taskflow e tooz con claim nel database.

Gestito dalla piattaforma Cloud Native

Monitor degli host masakari-monitors

Gestito da Medik8s

Perché è stato escluso

Kubernetes rileva già i nodi non integri: un NodeHealthCheck per segmento, con Self Node Remediation o Fence Agents Remediation, isola il nodo.

Perché la soluzione non ne risente

L'engine emette la stessa notifica COMPUTE_HOST una volta isolato il nodo, quindi l'evacuazione funziona come prima. I monitor di istanze e processi non sono ancora sostituiti.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Meccanismi interni semplificati

RPC oslo.messaging e coordinamento tooz

Gestito da Kubernetes Leases

Perché è stato escluso

L'API inserisce la riga di notifica e le repliche dell'engine la acquisiscono con un compare-and-swap; duplicati e lavoro per host sono serializzati da righe di database che funzionano tra i nodi Galera.

Perché la soluzione non ne risente

Non serve RabbitMQ e nessun cast può andare perso; il test Galera restituisce esattamente un 202 per 24 report identici concorrenti.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Meccanismi interni semplificati

Logbook taskflow e flussi di ripristino personalizzati

Perché è stato escluso

L'avanzamento è una tabella del database unico anziché un secondo database taskflow; Go non prevede il caricamento di plugin, quindi gli elenchi di flussi predefiniti sono integrati.

Perché la soluzione non ne risente

recovery_workflow_details restituisce lo stesso elenco di avanzamento. Elenchi di task personalizzati e task stevedore di terze parti non sono supportati.

Fonte: openkeel-masakari/docs/CONFORMANCE.md

Gestito dalla piattaforma Cloud Native

Opzioni del server WSGI, healthcheck, filtri osapi_v1

Gestito da Kubernetes probes

Perché è stato escluso

Un server HTTP in Go sostituisce lo stack WSGI, Kubernetes gestisce processi e probes, e le opzioni osapi_v1 sono deprecate upstream.

Perché la soluzione non ne risente

L'API e le sue microversion da 1.0 a 1.3 restano invariate.

Fonte: openkeel-masakari/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

Interazioni Masakari

Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.

Le 4 interazioni del modello

Da	A	Protocollo	Cosa
Masakari engine + monitors	Nova API	API REST	server state, host disable
Masakari API	Masakari engine + monitors	RabbitMQ	RPC notification
Masakari engine + monitors	Medik8s NHC + SNR	API Kubernetes	NodeHealthCheck, remediation status
Masakari engine + monitors	KubeVirt	API Kubernetes	VMI delete, live migration

Specifiche

Servizi

masakari

Branch stable-2026.2 · 8 file

Leggi la reverse-spec

Anche in Calcolo e capacità

Placement

Inventari delle risorse e allocazioni; il primo componente riscritto in Go.

GoMariaDB Galera

Nova

Le istanze girano come VirtualMachine KubeVirt; conductor con lo scheduler integrato nel processo, un agente per nodo.

GoKubeVirt e CDI

Zun

Containers as a Service: un Pod per container, isolato nella propria microVM Kata, con la sua porta Neutron come unica rete.

GoPod Kata

Ironic

Bare metal: resta Python upstream, impacchettato in un chart OpenKeel; troppe configurazioni hardware da testare.

Chart (Python upstream)Chart Helm (Python upstream)