Composants · Calcul et capacités

Masakari

Haute disponibilité des instances ; santé des nœuds par Node Healthcheck et Self Node Remediation.

Go Medik8sopenkeel-masakari

Le module

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

Extrait de openkeel-masakari/README.md (en anglais).

API REST

21 opérations de l'API REST d'origine (routes et actions de corps), et leur état dans OpenKeel.

21Implémenté

Voir chaque opération

Comment la compatibilité est testée

Les scénarios enregistrés de Masakari Python sont rejoués contre le service Go, le moteur de reprise est comparé aux appels Nova effectués par Python, et la concurrence est testée sur Galera.

Rejeu des échanges enregistrés

Rejeu E2E des scénarios enregistrés

Les 201 échanges de 23 scénarios ordonnés, avec le même faux Nova et les mêmes tâches périodiques, donnent les mêmes réponses que Python.

Exécution

make e2e, sur go-mysql-server et sur MariaDB 11.4 (E2E_MYSQL_DSN) ; make e2e-strict réussit.

Dernier résultat 195 / 201 sur les deux moteurs ; 6 différences volontaires listées dans test/e2e/known-differences.txt.

Source : openkeel-masakari/docs/CONFORMANCE.md

Contrat client

Moteur face aux appels Nova enregistrés

Les flux de reprise d'hôte et d'instance envoient à Nova les mêmes mutations, par serveur, service et agrégat, que le moteur Python.

Exécution

internal/engine/engine_test.go sur nova-calls_stable-2026.2.json (143 requêtes).

Dernier résultat Mutations identiques par serveur, service et agrégat ; les nombres de requêtes GET de polling ne sont pas comparés.

Source : openkeel-masakari/docs/CONFORMANCE.md

Tests unitaires et golden tests

Tests unitaires et de politique

Le routage d'API, les microversions, les messages de validation et les 24 règles de politique pour deux personas se comportent comme en Python.

Exécution

make test, avec des simulacres client-go pour l'intégration Kubernetes.

Dernier résultat Réussi.

Source : openkeel-masakari/docs/CONFORMANCE.md

Concurrence sur Galera

Concurrence sur MariaDB Galera

Noms uniques et notifications en double tiennent sur trois nœuds, et des moteurs sur trois nœuds n'évacuent un hôte qu'une seule fois.

Exécution

make galera-test sur un cluster à 3 nœuds.

Dernier résultat Réussi : segments et hôtes de même nom 1 × 201, 17 × 409 ; notifications en double 1 × 202, 23 × 409.

Source : openkeel-masakari/docs/CONFORMANCE.md

Tempest

Tests fonctionnels sur un cluster déployé

Tests fonctionnels de Masakari (openstacksdk) et tests de type Tempest contre un service déployé.

Exécution

Nécessitent un cluster déployé.

Dernier résultat Non exécuté.

Source : openkeel-masakari/docs/CONFORMANCE.md

Écarté de la réécriture

Masakari conserve son API et ses workflows de reprise mais détecte les pannes d'hôte avec Medik8s au lieu de masakari-monitors, et remplace RPC, taskflow et tooz par des réservations en base.

Assuré par la plateforme Cloud Native

Moniteur d'hôtes masakari-monitors

Repris par Medik8s

Pourquoi c'est écarté

Kubernetes détecte déjà les nœuds défaillants : un NodeHealthCheck par segment, avec Self Node Remediation ou Fence Agents Remediation, isole le nœud.

Pourquoi la solution n'est pas affectée

Le moteur émet la même notification COMPUTE_HOST une fois le nœud isolé : l'évacuation fonctionne comme avant. Les moniteurs d'instances et de processus ne sont pas encore remplacés.

Source : openkeel-masakari/docs/CONFORMANCE.md

Mécanique interne simplifiée

RPC oslo.messaging et coordination tooz

Repris par Kubernetes Leases

Pourquoi c'est écarté

L'API insère la ligne de notification et les répliques du moteur la réservent par compare-and-swap ; les doublons et le travail par hôte sont sérialisés par des lignes en base qui fonctionnent entre nœuds Galera.

Pourquoi la solution n'est pas affectée

Aucun RabbitMQ n'est nécessaire et aucun cast ne peut être perdu ; le test Galera donne exactement un 202 pour 24 rapports identiques concurrents.

Source : openkeel-masakari/docs/CONFORMANCE.md

Mécanique interne simplifiée

Logbook taskflow et flux de reprise personnalisés

Pourquoi c'est écarté

L'avancement est une table de la base unique au lieu d'une seconde base taskflow ; Go n'a pas de chargement de plugins, les listes de flux par défaut sont donc intégrées.

Pourquoi la solution n'est pas affectée

recovery_workflow_details renvoie la même liste d'avancement. Les listes de tâches personnalisées et les tâches stevedore tierces ne sont pas prises en charge.

Source : openkeel-masakari/docs/CONFORMANCE.md

Assuré par la plateforme Cloud Native

Options du serveur WSGI, healthcheck, filtres osapi_v1

Repris par Kubernetes probes

Pourquoi c'est écarté

Un serveur HTTP Go remplace la pile WSGI, Kubernetes gère les processus et les probes, et les options osapi_v1 sont dépréciées en amont.

Pourquoi la solution n'est pas affectée

L'API et ses microversions 1.0 à 1.3 sont inchangées.

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

Interactions de Masakari

Vue « service » générée par la skill diagramme depuis le modèle d'OpenKeel.

Les 4 interactions du modèle

De	Vers	Protocole	Quoi
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

Spécifications

Services

masakari

Branche stable-2026.2 · 8 fichiers

Lire la reverse-spec

Aussi dans « Calcul et capacités »

Placement

Inventaires et allocations de ressources ; premier composant réécrit en Go.

GoMariaDB Galera

Nova

Instances exécutées comme VirtualMachines KubeVirt ; conductor avec le scheduler intégré, un agent par nœud.

GoKubeVirt et CDI

Zun

Containers as a Service : un Pod par conteneur, isolé dans sa microVM Kata, avec son port Neutron comme seul réseau.

GoPods Kata

Ironic

Bare metal : reste en Python amont, empaqueté dans un chart OpenKeel ; trop de configurations matérielles à tester.

Chart (Python amont)Chart Helm (Python amont)