ThysTips_dn42/infra-dn42
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

fix(ingress) : Bird vient du même dépôt dans les conteneurs que sur les nœuds #27

Merged
thystips merged 2 commits from fix/bird-same-repo into main 2026-08-09 19:35:30 +02:00
Conversation 0 Commits 2 Files changed 5 +87 -20
thystips commented 2026-08-09 18:39:05 +02:00
Owner
Copy link

Le conteneur prenait la Bird de Debian — 3.1.7 contre 3.3.1 sur les nœuds. Signalé par Thys en relisant la PR #25.

Le motif que j'avais écrit alors : le conteneur ne fait ni Babel, ni BFD, ni RPKI, donc une Bird 3 quelconque suffit. C'est exact et à côté de la question. base disait déjà que « which Bird version stays a single decision in a single place », et deux versions dans un même AS finissent par se distinguer sur un détail que personne ne cherchait, un jour de diagnostic.

C'est aussi ce que la scission de base (PR #26) rendait possible sans que je l'exploite : le dépôt CZ.NIC était devenu disponible aux conteneurs sans le reste du rôle. Le play l'active donc à côté de celui de Grafana.

Pourquoi ce n'est pas simplement state: latest

Il fallait bien basculer les conteneurs déjà installés : present se contente de ce qui est là, donc le changement de dépôt ne se serait jamais fait.

Mais le laisser aurait signifié une montée de version à chaque exécution d'Ansible — donc un redémarrage de Bird, donc la VIP qui bat — sur le service le plus exposé de l'AS, et sans que personne l'ait décidé. Le dépôt dit « aucun redémarrage automatique » et « les montées de version sont un commit délibéré ».

La bascule est donc conditionnée à l'origine du paquet installé : c'est un changement de source, pas une montée de version, et la condition dit exactement ça. En régime établi, elle ne s'exécute jamais.

Un contrôle final lit l'origine plutôt qu'un numéro — le dépôt est ce qui garde les machines alignées, et épingler une version ici demanderait de la tenir en phase avec celle des nœuds. Sans lui, un apt_sources_cznic oublié réinstallerait la Debian en silence : le service marcherait, et l'AS aurait deux Bird sans que rien ne le dise.

Vérifié
Les quatre conteneurs 3.3.2, origine https://pkg.labs.nic.cz/bird3
Sessions iBGP Established sur les quatre
Service chaque nœud servi par son propre conteneur
Second passage changed=0 sur les douze hôtes

⚠ Un écart de patch subsiste, et il n'est pas de cette PR

Les nœuds sont en 3.3.1 : le rôle bird installe en state: present, et ils n'ont jamais monté depuis leur installation. Les conteneurs, installés maintenant, prennent la version courante du dépôt.

Les aligner sur 3.3.2 recycle toutes les sessions BGP de l'AS. C'est une opération à décider — un nœud à la fois, comme toute intervention sur le plan de données — pas quelque chose à glisser dans un correctif de dépôt.

Le conteneur prenait la Bird de **Debian** — `3.1.7` contre `3.3.1` sur les nœuds. Signalé par Thys en relisant la PR #25. Le motif que j'avais écrit alors : le conteneur ne fait ni Babel, ni BFD, ni RPKI, donc une Bird 3 quelconque suffit. C'est **exact et à côté de la question**. `base` disait déjà que « *which Bird version stays a single decision in a single place* », et deux versions dans un même AS finissent par se distinguer sur un détail que personne ne cherchait, un jour de diagnostic. C'est aussi ce que la scission de `base` (PR #26) rendait possible sans que je l'exploite : le dépôt CZ.NIC était devenu disponible aux conteneurs **sans** le reste du rôle. Le play l'active donc à côté de celui de Grafana. ## Pourquoi ce n'est pas simplement `state: latest` Il fallait bien basculer les conteneurs déjà installés : `present` se contente de ce qui est là, donc le changement de dépôt ne se serait jamais fait. Mais le **laisser** aurait signifié une montée de version à chaque exécution d'Ansible — donc un redémarrage de Bird, donc la VIP qui bat — sur le service le plus exposé de l'AS, et sans que personne l'ait décidé. Le dépôt dit « aucun redémarrage automatique » et « les montées de version sont un commit délibéré ». La bascule est donc conditionnée à l'**origine du paquet installé** : c'est un changement de source, pas une montée de version, et la condition dit exactement ça. En régime établi, elle ne s'exécute jamais. Un contrôle final lit l'origine plutôt qu'un numéro — le dépôt est ce qui garde les machines alignées, et épingler une version ici demanderait de la tenir en phase avec celle des nœuds. Sans lui, un `apt_sources_cznic` oublié réinstallerait la Debian **en silence** : le service marcherait, et l'AS aurait deux Bird sans que rien ne le dise. ## Vérifié | | | |---|---| | Les quatre conteneurs | `3.3.2`, origine `https://pkg.labs.nic.cz/bird3` | | Sessions iBGP | `Established` sur les quatre | | Service | chaque nœud servi par son propre conteneur | | Second passage | `changed=0` sur les douze hôtes | ## ⚠ Un écart de patch subsiste, et il n'est pas de cette PR Les nœuds sont en **3.3.1** : le rôle `bird` installe en `state: present`, et ils n'ont jamais monté depuis leur installation. Les conteneurs, installés maintenant, prennent la version courante du dépôt. Les aligner sur 3.3.2 **recycle toutes les sessions BGP de l'AS**. C'est une opération à décider — un nœud à la fois, comme toute intervention sur le plan de données — pas quelque chose à glisser dans un correctif de dépôt.
Le conteneur prenait la Bird de Debian — 3.1.7 contre 3.3.1 sur les nœuds. Le
motif écrit alors était qu'il ne fait ni Babel, ni BFD, ni RPKI, donc qu'une
Bird 3 quelconque suffit. C'est exact et à côté de la question : `base` disait
déjà que « quelle version de Bird » doit rester une décision en UN SEUL endroit,
et deux versions dans un même AS finissent par se distinguer sur un détail que
personne ne cherchait, un jour de diagnostic. Signalé par Thys.

C'est aussi ce que la scission de `base` rendait possible sans que je
l'exploite : le dépôt CZ.NIC était devenu disponible aux conteneurs sans le
reste du rôle. Le play l'active donc à côté de celui de Grafana.

⚠ PAS `state: latest` EN PERMANENCE. Il fallait bien basculer les conteneurs
déjà installés — `present` se contente de ce qui est là, donc le changement de
dépôt ne se serait jamais fait — mais le laisser aurait signifié une montée de
version à chaque exécution d'Ansible, donc un redémarrage de Bird, donc la VIP
qui bat, sur le service le plus exposé de l'AS et sans que personne l'ait
décidé. Le dépôt dit « aucun redémarrage automatique ». La bascule est donc
conditionnée à l'ORIGINE du paquet installé : c'est un changement de source, pas
une montée de version, et la condition dit exactement ça.

Un contrôle final lit l'origine plutôt qu'un numéro : le dépôt est ce qui garde
les machines alignées, et épingler une version ici demanderait de la tenir en
phase avec celle des nœuds. Sans ce contrôle, un `apt_sources_cznic` oublié
réinstallerait la Debian en silence — le service marcherait, et l'AS aurait deux
Bird sans que rien ne le dise.

Vérifié : les quatre conteneurs en 3.3.2 depuis pkg.labs.nic.cz, sessions iBGP
établies, chaque nœud servi par son propre conteneur, `changed=0` sur les douze
hôtes.

⚠ RESTE UN ÉCART DE PATCH, et il n'est pas de ce commit : les nœuds sont en
3.3.1 parce que le rôle `bird` installe en `state: present` et qu'ils n'ont
jamais monté. Les aligner sur 3.3.2 recycle toutes les sessions BGP de l'AS —
c'est une opération à décider, pas à glisser dans un correctif de dépôt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
Aligner les nœuds sur les conteneurs aurait suffi aujourd'hui et aurait
re-divergé au prochain conteneur créé : sans épinglage, une machine prend ce que
le dépôt propose LE JOUR DE SON INSTALLATION. C'est littéralement ce qui s'est
passé — les nœuds installés quand 3.3.1 était courante, les conteneurs quand
3.3.2 l'était, et rien pour le dire.

`dn42_bird_version` vit donc dans `group_vars/all/`, le seul endroit que les
deux rôles voient. C'est une décision d'AS, au même titre que le MTU de
l'overlay ou le choix de l'IGP.

⚠ ÉPINGLÉE ET NON `state: latest`. Celui-ci monterait Bird à chaque exécution
d'Ansible — donc redémarrerait le démon et ferait battre toutes les sessions BGP
du nœud — sans décision humaine. Le dépôt dit « aucun redémarrage automatique »
et « les montées de version sont un commit délibéré ». Monter Bird est
maintenant UNE LIGNE à changer, puis un déroulé `--limit` par `--limit`.

Ça remplace la bascule conditionnelle du commit précédent, qui visait l'origine
du paquet : la version épinglée fait TROIS choses d'un coup — elle aligne, elle
garantit l'origine (le suffixe `cznic` n'existe que dans ce dépôt), et elle fait
échouer FRANCHEMENT un `apt_sources_cznic` oublié là où un `present` nu aurait
posé la Bird de Debian en silence. Le contrôle d'origine devient donc inutile et
part avec elle.

`allow_downgrade` : une version épinglée plus basse est un retour arrière voulu,
c'est la moitié « rollback » de la même règle.

DÉROULÉ NŒUD PAR NŒUD, sessions surveillées entre chacun. Le postinst redémarre
le démon, donc elles sont toutes recyclées — 9/12, 4/10, 9/11, 3/9 juste après,
et retour au compte d'origine en une à deux minutes à chaque fois. Le service
d'ingress a répondu pendant toute l'opération.

⚠ `collector_grc` est en `Active`/`OpenSent` avec « Connection reset by peer », et
ce N'EST PAS cette montée : le journal le montre en `Hold timer expired` à
16:09 UTC, une heure AVANT (17:02 UTC). Le TCP/179 vers le pair est ouvert, c'est
lui qui coupe après l'OPEN. Un `birdc restart` n'y a rien changé — collecteur
externe, sans effet sur le service.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
thystips deleted branch fix/bird-same-repo 2026-08-09 19:35:30 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ThysTips_dn42/infra-dn42!27
No description provided.