Un satellite réel tourne sur les ports du slot 00 du gabarit sans figurer dans reference/satellites.md, et rien ne le détecte #74

Closed
opened 2026-09-17 06:12:32 +00:00 by nicolas-fryder · 1 comment

Ce qui ne va pas

reference/satellites.md réserve les ports « avant le clonage pour que deux
satellites sur un même poste ne se marchent pas dessus » (D-030). Le satellite
nicolas-fryder/projet (service atelier, profil nest) n'y figure pas, et il
tourne sur exactement la ligne 00 | template :

api web postgres otel
00 | template (registre) 4100 4000 55400 43100
nicolas-fryder/projet (.env) 4100 4000 55400 43100

Il hérite ces valeurs du gabarit et personne ne lui en a jamais attribué
d'autres : le clonage copie .env.example, qui porte les ports du slot 00.

Ce que ça coûte

Aujourd'hui, rien — une seule application tourne à la fois sur ce poste. Le jour
où le gabarit lui-même, ou un second satellite non enregistré, est levé à côté :
port is already allocated sur Postgres et sur le collecteur, et deux services
qui se disputent 4000/4100.

Le correctif de #62 ferme la moitié du problème et en éclaire l'autre : Compose
refuse désormais de lever sans SERVICE_NAME unique, donc les bases ne se
mélangent plus
. Mais SERVICE_NAME ne gouverne pas les ports, et le registre
qui les gouverne n'est vérifié par personne :

  • eqs doctor ne lit pas reference/satellites.md — il ne peut pas, le fichier
    vit dans un autre dépôt ;
  • aucun contrôle ne compare les PORT_* du .env.example d'un satellite à ce
    que le registre lui a réservé ;
  • le message de .env.example dit « réservés au clonage, cf.
    eqs-platform/reference/satellites.md », mais rien n'oblige à y aller, et un
    clone qui n'y va pas garde les ports du gabarit en croyant les avoir
    reçus
    .

C'est la même forme que #62 : un conflit qui ne se voit pas parce que le mode
d'échec est un succès sur la mauvaise ressource — sauf que là, le succès dure
jusqu'au jour où quelqu'un lève deux piles.

Ce que je proposerais

  1. Attribuer une ligne à ce dépôt (le premier satellite réel de la flotte),
    avec ses quatre ports, et me dire lesquels — je mets .env.example,
    .env et docker-compose.yml à jour dans la foulée. Sans ça, la seule
    valeur que le registre porte pour l'instant est celle du gabarit lui-même.

  2. Un contrôle qui rende le registre opposable. Deux formes possibles, de la
    moins à la plus ambitieuse :

    • cli.ports-du-gabarit : refuser les ports du slot 00 dans un dépôt dont
      le package.json ne s'appelle pas eqs-satellite-template. C'est trois
      comparaisons, et ça attrape exactement le cas « personne n'a réservé » ;
    • une réservation lisible depuis le satellite — un champ eqs.slot dans le
      package.json, ou un satellites.json publié par @eqs/cli — que
      eqs doctor confronte aux PORT_* effectifs.

    La première suffit à fermer le défaut, et elle ne demande aucun mécanisme
    neuf. eqs-fleet étant reporté (D-030), c'est le genre de garde qui rend le
    report tenable.

  3. Accessoirement : l'étape correspondante d'initialiser-un-satellite.md
    gagnerait à dire « ouvrir un ticket pour obtenir un slot » plutôt que
    « consulter le registre » — consulter n'alloue rien, et c'est ce qui manque.

Versions

eqs --version 0.11.2, @eqs/* tous en 0.11.2, gabarit
eqs-satellite-template@53e704c, profil nest.

## Ce qui ne va pas `reference/satellites.md` réserve les ports « avant le clonage pour que deux satellites sur un même poste ne se marchent pas dessus » (D-030). Le satellite `nicolas-fryder/projet` (service `atelier`, profil `nest`) n'y figure pas, et il tourne sur **exactement la ligne `00 | template`** : | | api | web | postgres | otel | |---|---|---|---|---| | `00 \| template` (registre) | 4100 | 4000 | 55400 | 43100 | | `nicolas-fryder/projet` (`.env`) | 4100 | 4000 | 55400 | 43100 | Il hérite ces valeurs du gabarit et personne ne lui en a jamais attribué d'autres : le clonage copie `.env.example`, qui porte les ports du slot `00`. ## Ce que ça coûte Aujourd'hui, rien — une seule application tourne à la fois sur ce poste. Le jour où le gabarit lui-même, ou un second satellite non enregistré, est levé à côté : `port is already allocated` sur Postgres et sur le collecteur, et deux services qui se disputent 4000/4100. Le correctif de #62 ferme la moitié du problème et en éclaire l'autre : Compose refuse désormais de lever sans `SERVICE_NAME` unique, donc **les bases ne se mélangent plus**. Mais `SERVICE_NAME` ne gouverne pas les ports, et le registre qui les gouverne n'est vérifié par personne : - `eqs doctor` ne lit pas `reference/satellites.md` — il ne peut pas, le fichier vit dans un autre dépôt ; - aucun contrôle ne compare les `PORT_*` du `.env.example` d'un satellite à ce que le registre lui a réservé ; - le message de `.env.example` dit « réservés au clonage, cf. `eqs-platform/reference/satellites.md` », mais rien n'oblige à y aller, et un clone qui n'y va pas garde les ports du gabarit **en croyant les avoir reçus**. C'est la même forme que #62 : un conflit qui ne se voit pas parce que le mode d'échec est un succès sur la mauvaise ressource — sauf que là, le succès dure jusqu'au jour où quelqu'un lève deux piles. ## Ce que je proposerais 1. **Attribuer une ligne** à ce dépôt (le premier satellite réel de la flotte), avec ses quatre ports, et me dire lesquels — je mets `.env.example`, `.env` et `docker-compose.yml` à jour dans la foulée. Sans ça, la seule valeur que le registre porte pour l'instant est celle du gabarit lui-même. 2. **Un contrôle qui rende le registre opposable.** Deux formes possibles, de la moins à la plus ambitieuse : - `cli.ports-du-gabarit` : refuser les ports du slot `00` dans un dépôt dont le `package.json` ne s'appelle pas `eqs-satellite-template`. C'est trois comparaisons, et ça attrape exactement le cas « personne n'a réservé » ; - une réservation lisible depuis le satellite — un champ `eqs.slot` dans le `package.json`, ou un `satellites.json` publié par `@eqs/cli` — que `eqs doctor` confronte aux `PORT_*` effectifs. La première suffit à fermer le défaut, et elle ne demande aucun mécanisme neuf. `eqs-fleet` étant reporté (D-030), c'est le genre de garde qui rend le report tenable. 3. Accessoirement : l'étape correspondante d'`initialiser-un-satellite.md` gagnerait à dire « ouvrir un ticket pour obtenir un slot » plutôt que « consulter le registre » — consulter n'alloue rien, et c'est ce qui manque. ## Versions `eqs --version` 0.11.2, `@eqs/*` tous en 0.11.2, gabarit `eqs-satellite-template@53e704c`, profil `nest`.
Author
Owner

Corrigé en 0.12.0, et votre point 1 comme votre point 3 sont faits.

Le contrôle — votre voie la plus simple, retenue telle quelle. cli.ports-du-gabarit (bloquant) refuse deux valeurs ou plus du quatuor 4100 / 4000 / 55400 / 43100 dans .env.example ou .env, quand le package.json ne s'appelle pas eqs-satellite-template. Le seuil de deux EST le contrôle : 4000 est un port ordinaire, et un contrôle qui rougit sur une coïncidence est un contrôle qu'on franchit. Voir D-047.

La ligne. nicolas-fryder/projet figure au registre, slot 03 — et pas 02 comme attribué d'abord. La raison vaut d'être dite, parce qu'elle prolonge votre ticket : deux attributions faites en lisant reference/satellites.md ont été démenties par la machine. Le 02 croisait nuage, qui tient 4002 et ne figurait nulle part ; le 03 donné à eqs-demo a répondu port is already allocated sur 55403 — votre .env. Le registre ne disait pas ce qui était pris, seulement ce qui était réservé.

Le fichier porte donc maintenant la règle qui manquait : attribuer un slot se vérifie contre docker ps, pas contre ce fichier. nuage est entré au tableau, les slots hors service (01, 02, 06) ont leur raison écrite, et eqs-demo a pris le 05, éprouvé en levant sa pile et en lisant les ports publiés.

Le mot qui manquait, votre point 3 : docs/initialiser-un-satellite.md dit désormais « obtenir un slot » là où il disait « consulter le registre ». Consulter n'alloue rien — c'est exactement ce qui s'est passé.

Ce qui reste chez vous : votre .env.example committé annonce encore 02. Il est à passer en 03 pour s'aligner sur votre .env et sur le registre ; tant qu'il dit 02, un clone repartirait sur 4002, qu'occupe nuage. Rien n'a été touché dans votre dépôt.

Fermé le 2026-09-21. Ce ticket restait ouvert faute d'un Closes #74 dans le commit, pas faute de correctif.

Corrigé en **0.12.0**, et votre point 1 comme votre point 3 sont faits. **Le contrôle** — votre voie la plus simple, retenue telle quelle. `cli.ports-du-gabarit` (bloquant) refuse **deux valeurs ou plus** du quatuor `4100 / 4000 / 55400 / 43100` dans `.env.example` ou `.env`, quand le `package.json` ne s'appelle pas `eqs-satellite-template`. Le seuil de deux EST le contrôle : `4000` est un port ordinaire, et un contrôle qui rougit sur une coïncidence est un contrôle qu'on franchit. Voir **D-047**. **La ligne.** `nicolas-fryder/projet` figure au registre, slot `03` — et pas `02` comme attribué d'abord. La raison vaut d'être dite, parce qu'elle prolonge votre ticket : **deux attributions faites en lisant `reference/satellites.md` ont été démenties par la machine.** Le `02` croisait `nuage`, qui tient `4002` et ne figurait nulle part ; le `03` donné à `eqs-demo` a répondu `port is already allocated` sur 55403 — votre `.env`. Le registre ne disait pas ce qui était **pris**, seulement ce qui était réservé. Le fichier porte donc maintenant la règle qui manquait : **attribuer un slot se vérifie contre `docker ps`, pas contre ce fichier.** `nuage` est entré au tableau, les slots hors service (01, 02, 06) ont leur raison écrite, et `eqs-demo` a pris le `05`, éprouvé en levant sa pile et en lisant les ports publiés. **Le mot qui manquait**, votre point 3 : `docs/initialiser-un-satellite.md` dit désormais « obtenir un slot » là où il disait « consulter le registre ». Consulter n'alloue rien — c'est exactement ce qui s'est passé. **Ce qui reste chez vous** : votre `.env.example` committé annonce encore `02`. Il est à passer en `03` pour s'aligner sur votre `.env` et sur le registre ; tant qu'il dit `02`, un clone repartirait sur `4002`, qu'occupe `nuage`. Rien n'a été touché dans votre dépôt. Fermé le 2026-09-21. Ce ticket restait ouvert faute d'un `Closes #74` dans le commit, pas faute de correctif.
Sign in to join this conversation.
No milestone
No project
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
Infrastructure/eqs-platform#74
No description provided.