From 642a9c2f7ae3ff0470045b7503ca1b6a23f59c60 Mon Sep 17 00:00:00 2001 From: GnomeZworc Date: Tue, 25 Aug 2026 23:56:55 +0200 Subject: [PATCH] f-33: doc: update release note Signed-off-by: GnomeZworc --- release_notes/0.1.0.md | 41 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/release_notes/0.1.0.md b/release_notes/0.1.0.md index be3d69c..d8b1bab 100644 --- a/release_notes/0.1.0.md +++ b/release_notes/0.1.0.md @@ -11,23 +11,48 @@ Première version stable de **syonad/two**, orchestrateur réseau et VM mono-nœ avec `error` en cas d'échec d'exécution ; suppression autorisée depuis `running` et `error` - Migration au démarrage de l'agent : toute ressource restée dans un état transitoire est basculée en `error`, la file de travail étant en mémoire +- Arrêt gracieux : serveurs HTTP, puis drainage des workers, puis fermeture de la base. Si le + budget d'arrêt est dépassé, la base n'est **pas** fermée — la rejouer au démarrage suivant vaut + mieux que de la fermer sous un écrivain concurrent **Réseau** - VPC isolés par network namespace, subnets en mode `vxlan` ou `bridge` -- DHCP par subnet via instances `dnsmasq@` dédiées, entrées ip→mac en base -- Route par défaut et route du VPC distribuées par DHCP (`default_route` par subnet) +- DHCP par subnet via instances `dnsmasq@` dédiées, entrées ip→mac en base, fichier de baux propre + à chaque instance +- Toutes les routes sont distribuées par l'option 121 : route vers le serveur de metadata, route du + VPC, et route par défaut. L'option 3 reste émise pour les clients qui n'implémentent pas la 121 +- `default_route` choisit le **next-hop** de la route par défaut : l'`interface_ip` du subnet par + défaut, sinon la `gateway` fournie ou celle déduite de l'host +- `gateway` optionnelle par subnet, non validée par l'agent - Isolation du DHCP par ebtables, redirection du service de metadata par iptables **Machines virtuelles** +- Plusieurs interfaces réseau par VM, dans un même VPC. La position de l'interface détermine son + slot PCI, donc son nom dans le guest ; **exactement une** interface est primaire et porte la route + par défaut et le serveur de metadata - Démarrage QEMU/KVM avec plusieurs disques et ordre de démarrage explicite - Amorçage UEFI optionnel (OVMF), avec magasin de variables par VM - Serveur de metadata cloud-init par VM (`metadata@`), sans base de données dans le processus - Les VMs survivent à l'arrêt de l'agent : QEMU est lancé hors de son cgroup via `systemd-run` +**Metadata cloud-init** + +- Objet `metadata` dans la création de VM : `password`, `sshkey`, `user_data` +- `user_data` transmis en base64, ce qui autorise les charges gzip+base64 ; un encodage invalide est + refusé en 400, jamais servi vide en silence +- Un document fourni est servi **verbatim**, un document absent retombe sur le modèle par défaut, et + un document explicitement vide est servi vide — les trois cas sont distincts +- Le compte `syonad` n'est créé que si un mot de passe ou une clé est fourni, et reste verrouillé + quand seule une clé l'est. L'agent n'impose aucune modification du compte root + **Exploitation** +- Watchdog de cohérence : vérifie périodiquement que les ressources `running` existent encore sur + le système et signale les écarts. Lecture seule, il ne répare jamais. Désactivé par défaut, + activé dans le fichier d'exemple +- API d'administration en lecture seule sur la boucle locale, pour inspecter la base - Métriques Prometheus : nombre de VPC, subnets et VMs par état - `deploy.sh` avec profils d'host (`kvm`), préparation système déléguée à `bootstrap_kvm.sh` - Units systemd et scripts publiés comme assets de release, avec manifeste `SHA256SUMS` @@ -39,7 +64,17 @@ Première version stable de **syonad/two**, orchestrateur réseau et VM mono-nœ - Pas de rollback en cas d'échec partiel d'une création — les ressources réseau orphelines ne sont pas nettoyées automatiquement - API destinée à un appelant logiciel : la validation de cohérence des entrées (CIDR, VXLAN - ID, format des noms) est à la charge de l'appelant + ID, format des noms, joignabilité d'une `gateway`) est à la charge de l'appelant +- Le mode de subnet `public_ip` est accepté par l'API et par la sélection des routes DHCP, mais sa + mise en place réseau n'existe pas : créer un tel subnet échoue explicitement +- Les interfaces multiples d'une VM doivent appartenir au même VPC +- Le réseau des guests est configuré par le DHCP seul ; le `network-config` cloud-init servi est + sans effet et ne doit pas être « corrigé » sans mesurer l'impact sur les VM existantes +- Modifier les routes d'une VM déjà démarrée ne prend effet qu'au renouvellement du bail, soit + jusqu'à six heures plus tard, ou à son redémarrage +- `vm//password` contient un **hash**, stocké en clair en base et restitué par l'API + d'administration ; celle-ci est désactivée par défaut et n'écoute que sur la boucle locale +- L'API de l'agent n'a pas d'authentification : son exposition réseau doit être restreinte - Les packages `internal/netns`, `netif`, `qemu`, `vm`, `iptables` et `ebtables` ne fonctionnent que sous Linux