[infra] MLflow cassé par une reconstruction : les dépendances transitives ne sont pas épinglées #130

New issue

Closed

opened 2026-09-03 15:14:17 +00:00 by lenaic · 0 comments

lenaic commented

2026-09-03 15:14:17 +00:00

Owner

Exigence couverte

ENF-09, EF-07

Épreuve servie

EC06 · IA et automatisation

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

Remettre MLflow en service et empêcher que ça recommence.

Il est tombé le 3 septembre à 17 h 08, pendant le déploiement déclenché par la fusion vers main, et il a fait échouer ce déploiement — wait: true attend une pile saine, elle ne l'est jamais devenue.

AttributeError: module 'anyio' has no attribute 'from_thread'
  starlette/middleware/wsgi.py, ligne 136

La cause n'est pas MLflow, c'est ce qui l'entoure. infra/compose/mlflow/requirements.txt épingle mlflow==3.15.2, psycopg2-binary et boto3 — et le dit très bien : « une image reconstruite six semaines plus tard doit poser les mêmes octets ». Mais les dépendances transitives ne le sont pas. Le conteneur porte aujourd'hui starlette 1.6.0 et anyio 4.15.0, tirés à la reconstruction, et incompatibles entre eux.

Ce qui a déclenché la reconstruction : la pile mlflow porte build: true dans app_stacks, et la boucle de démarrage passe build: always. Chaque déploiement reconstruit donc l'image et rejoue la loterie des versions. Elle tournait « Up 21 hours (healthy) » ce matin avec les mêmes fichiers.

Critères d'acceptation

MLflow répond et son conteneur est healthy.
Les dépendances transitives sont épinglées, par un pip freeze de l'image qui marchait ou par des contraintes explicites sur starlette et anyio.
Une reconstruction de l'image donne le même résultat deux fois de suite : docker compose build --no-cache puis démarrage, deux fois.
Le choix build: always est tranché : soit il reste et les épinglages le rendent sûr, soit il passe à missing et une reconstruction se demande explicitement. Le motif est écrit.
Le déploiement continu repasse au vert sur main.

Comment on le vérifie

Commande curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:5000/
Preuve docker ps montre ev-mlflow healthy
Preuve deux constructions successives donnent les mêmes versions de starlette et anyio

Hors périmètre

Le reste de la pile : PostgreSQL, MinIO, la supervision et le collecteur n'ont pas été touchés et tournent. Le déploiement a échoué sur ce seul point.

Le même risque existe pour la pile postgres, qui porte aussi build: true. Elle a survécu à la reconstruction, mais pour la même raison de chance.

### Exigence couverte ENF-09, EF-07 ### Épreuve servie EC06 · IA et automatisation ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir Remettre MLflow en service et empêcher que ça recommence. **Il est tombé le 3 septembre à 17 h 08**, pendant le déploiement déclenché par la fusion vers `main`, et il a fait échouer ce déploiement — `wait: true` attend une pile saine, elle ne l'est jamais devenue. ``` AttributeError: module 'anyio' has no attribute 'from_thread' starlette/middleware/wsgi.py, ligne 136 ``` **La cause n'est pas MLflow, c'est ce qui l'entoure.** `infra/compose/mlflow/requirements.txt` épingle `mlflow==3.15.2`, `psycopg2-binary` et `boto3` — et le dit très bien : « une image reconstruite six semaines plus tard doit poser les mêmes octets ». Mais les dépendances **transitives** ne le sont pas. Le conteneur porte aujourd'hui `starlette 1.6.0` et `anyio 4.15.0`, tirés à la reconstruction, et incompatibles entre eux. **Ce qui a déclenché la reconstruction** : la pile `mlflow` porte `build: true` dans `app_stacks`, et la boucle de démarrage passe `build: always`. Chaque déploiement reconstruit donc l'image et rejoue la loterie des versions. Elle tournait « Up 21 hours (healthy) » ce matin avec les mêmes fichiers. ### Critères d'acceptation - [x] MLflow répond et son conteneur est `healthy`. - [x] Les dépendances transitives sont épinglées, par un `pip freeze` de l'image qui marchait ou par des contraintes explicites sur `starlette` et `anyio`. - [x] Une reconstruction de l'image donne le même résultat deux fois de suite : `docker compose build --no-cache` puis démarrage, deux fois. - [x] Le choix `build: always` est tranché : soit il reste et les épinglages le rendent sûr, soit il passe à `missing` et une reconstruction se demande explicitement. Le motif est écrit. - [x] Le déploiement continu repasse au vert sur `main`. ### Comment on le vérifie Commande curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:5000/ Preuve docker ps montre ev-mlflow healthy Preuve deux constructions successives donnent les mêmes versions de starlette et anyio ### Hors périmètre Le reste de la pile : PostgreSQL, MinIO, la supervision et le collecteur n'ont pas été touchés et tournent. Le déploiement a échoué sur ce seul point. Le même risque existe pour la pile `postgres`, qui porte aussi `build: true`. Elle a survécu à la reconstruction, mais pour la même raison de chance.

lenaic added the

labels

2026-09-03 15:14:17 +00:00