g2/enervision

Watch

Fork 0

[infra] MLflow, registre de modèles #30

New issue

Closed

opened 2026-09-01 10:35:24 +00:00 by lenaic · 2 comments

lenaic commented

2026-09-01 10:35:24 +00:00

Owner

Exigence couverte

ENF-09

Épreuve servie

EC06 · IA et automatisation

Charge estimée

1 j.h

Ce qu'on veut obtenir

Disposer d'un registre où les modèles entraînés sont versionnés, comparés et promus, avec les artefacts dans MinIO et le suivi dans PostgreSQL.

Critères d'acceptation

Le serveur répond sur 127.0.0.1:5000 et n'est pas joignable de l'extérieur.
Le suivi des exécutions est stocké dans un schéma dédié de PostgreSQL, pas en fichiers.
Les artefacts sont écrits dans le bucket mlflow de MinIO.
Une exécution factice est enregistrée puis retrouvée dans l'interface.

Comment on le vérifie

Commande une exécution mlflow d'exemple, puis lecture dans l'interface
Attendu l'exécution visible, l'artefact présent dans MinIO
Preuve capture de l'exécution et sortie mc ls du bucket

Manuel d'exploitation à mettre à jour

docs/runbooks/mlflow.md, promotion d'un modèle

Risque et retour arrière

Le stockage en fichiers est le défaut de MLflow et ne survit pas à une reconstruction du serveur. Vérifier que le paramètre de suivi pointe bien sur PostgreSQL.

### Exigence couverte ENF-09 ### Épreuve servie EC06 · IA et automatisation ### Charge estimée 1 j.h ### Ce qu'on veut obtenir Disposer d'un registre où les modèles entraînés sont versionnés, comparés et promus, avec les artefacts dans MinIO et le suivi dans PostgreSQL. ### Critères d'acceptation - [x] Le serveur répond sur 127.0.0.1:5000 et n'est pas joignable de l'extérieur. - [x] Le suivi des exécutions est stocké dans un schéma dédié de PostgreSQL, pas en fichiers. - [x] Les artefacts sont écrits dans le bucket mlflow de MinIO. - [x] Une exécution factice est enregistrée puis retrouvée dans l'interface. ### Comment on le vérifie Commande une exécution mlflow d'exemple, puis lecture dans l'interface Attendu l'exécution visible, l'artefact présent dans MinIO Preuve capture de l'exécution et sortie mc ls du bucket ### Manuel d'exploitation à mettre à jour docs/runbooks/mlflow.md, promotion d'un modèle ### Risque et retour arrière Le stockage en fichiers est le défaut de MLflow et ne survit pas à une reconstruction du serveur. Vérifier que le paramètre de suivi pointe bien sur PostgreSQL.

lenaic added the

labels

2026-09-01 10:35:24 +00:00

justine was assigned by lenaic

2026-09-01 10:35:24 +00:00

lenaic added a new dependency

2026-09-01 10:36:09 +00:00

#28 [infra] Installation de MinIO, buckets du médaillon et rétention

lenaic added a new dependency

2026-09-01 10:36:09 +00:00

#26 [Infra] Installation PostgreSQL 17

lenaic added a new dependency

2026-09-01 10:36:09 +00:00

#36 [EF-07] Entraînement du modèle et promotion

florian added this to the EnerVision project

2026-09-01 12:06:36 +00:00

olivier was assigned by lenaic

2026-09-02 09:59:21 +00:00

olivier referenced this issue

2026-09-02 12:12:35 +00:00

[infra] Installation de MinIO, buckets du médaillon et rétention #28

olivier commented

2026-09-02 12:47:25 +00:00

Member

État au 2 septembre : service installé et en service, 2 critères sur 4 éprouvés

Le registre tourne sur ml-stagiaire-02. Branche olivier/30-mlflow-registre,
pas encore de demande de fusion.

Critère	État
Répond sur `127.0.0.1:5000`, injoignable de l'extérieur	✅ éprouvé depuis un poste tiers
Suivi dans un schéma dédié de PostgreSQL, pas en fichiers	✅ 59 tables dans la base `mlflow`, aucun magasin fichier
Artefacts dans le bucket `mlflow` de MinIO	❌ bloqué : MinIO n'est pas déployé (#28)
Exécution factice enregistrée puis retrouvée	⚠️ enregistrée et retrouvée ; l'artefact échoue, l'exécution finit `FAILED`

Le blocage : le #28 est fusionné dans develop mais rien ne tourne sur le
serveur — pas de conteneur MinIO, rien sur 9000/9001, pas de
/etc/enervision/minio.env, mc absent. Sans bucket ni identifiants, les deux
derniers critères sont hors d'atteinte. Rien à corriger de mon côté : le
mandataire d'artefacts fonctionne, les artifact_uri sont bien en
mlflow-artifacts:/, c'est la destination qui manque.

Quand MinIO tournera, il reste vingt minutes : jouer
genere-identifiants.sh, le contrôle de fumée, le test complet, retirer le
bandeau du manuel, coller la sortie mc ls.

Preuves (sorties collées du serveur)

$ sudo docker compose ps
NAME        STATUS                    IMAGE
ev-mlflow   Up 10 minutes (healthy)   enervision/mlflow:3.15.2

$ sudo ss -ltnp | grep :5000
LISTEN 0      2048       127.0.0.1:5000       0.0.0.0:*    users:(("python3.12",pid=1276181,fd=3),("python3.12",pid=1276180,fd=3),("python3.12",pid=1276177,fd=3))

$ curl -fsS http://127.0.0.1:5000/health
OK

$ psql -d mlflow -c "<tables et propriétaire>"
59 tables dans public, possédées par mlflow

$ sudo docker exec ev-mlflow sh -c "ls -d /home/mlflow/mlruns 2>/dev/null || echo aucun-magasin-fichier"
aucun-magasin-fichier

$ sudo ps -eo args | grep "mlflow server" | head -1
/usr/local/bin/python3.12 /usr/local/bin/mlflow server --host 127.0.0.1 --port 5000 --backend-store-uri postgresql+psycopg2://mlflow@127.0.0.1:5433/mlflow --serve-artifacts --artifacts-destination s3://mlflow/ --workers 2

$ psql -d mlflow -c "<exécution factice>"
    experience     | status |                          artifact_uri                          | params | metriques 
-------------------+--------+----------------------------------------------------------------+--------+-----------
 controle-de-fumee | FAILED | mlflow-artifacts:/1/597f5dbe0228471e9c80e8a459e0df26/artifacts |      2 |         1
 controle-de-fumee | FAILED | mlflow-artifacts:/1/3bbf5d46d65242e0b68250bfbc30c458/artifacts |      2 |         1
(2 lignes)


$ pytest tests/integration/test_registre_mlflow.py
=========================== short test summary info ============================
FAILED tests/integration/test_registre_mlflow.py::test_l_execution_factice_est_retrouvee
1 failed, 9 passed, 4 skipped in 0.57s

Depuis un poste tiers de la salle, la vérification qui compte :

$ curl -sS --max-time 5 http://10.105.200.41:5000/health
curl: (28) Connection timed out after 5004 milliseconds

$ nc -z -G 5 10.105.200.41 22   -> succeeded    (contre-épreuve)
$ nc -z -G 5 10.105.200.41 5000 -> refusé       (attendu)
$ nc -z -G 5 10.105.200.41 5433 -> refusé       (attendu, décision #65)

L'unique échec du test est le bon : il détecte précisément l'absence de MinIO.

Ce que le chantier a produit

infra/compose/mlflow/ — image maison (base épinglée réutilisée de la
chaîne), composition en réseau hôte, générateur d'identifiants, contrôle de
fumée. Aucun volume : tout l'état est dans les deux magasins, déjà
sauvegardés, et le conteneur est jetable.
docs/runbooks/mlflow.md — dont la promotion d'un modèle, par alias et non
par « stage », qui est déprécié.
docs/adr/0002-mlflow-mandataire-artefacts.md — les artefacts passent par
le serveur : les clients des #36 et #37 n'ont besoin que de
MLFLOW_TRACKING_URI, aucun identifiant MinIO ne quitte la machine.
tests/integration/test_registre_mlflow.py — un cas par critère, plus le
cloisonnement de l'utilisateur MinIO dédié.

Deux défauts trouvés en le faisant tourner, et corrigés

useradd --system avec --uid 1001 : l'image sortait sur un avertissement.
Plus sérieux : MLFLOW_S3_ENDPOINT_URL était dans le fichier de secrets.
Fichier incomplet → variable absente → boto3 s'est rabattu sur le vrai AWS
S3, et le client a pendu deux minutes sans qu'aucun message ne dise que la
requête partait vers Internet. Une variable qui, absente, change la cible
d'une écriture n'a pas sa place dans un fichier qu'on peut écrire à moitié :
elle est passée dans la composition versionnée, avec des bornes de reprise.
L'échec prend maintenant 18 s et nomme la cause.

À savoir pour la suite

#36 peut déjà travailler : paramètres, métriques et modèles enregistrés
fonctionnent. Seuls les artefacts échouent.
Ce ticket dépend du #80 pour la fusion : le manuel renvoie à la pile
PostgreSQL, qui tourne sur le serveur mais dont les commits ne sont pas dans
develop — et le #80 n'a aucune demande de fusion ouverte.
/etc/enervision/mlflow.env est écrit à la main, avec le seul mot de
passe PostgreSQL, et porte un en-tête qui dit qu'il est incomplet. Il sera
remplacé par le générateur.

### État au 2 septembre : service installé et en service, 2 critères sur 4 éprouvés Le registre tourne sur `ml-stagiaire-02`. Branche `olivier/30-mlflow-registre`, pas encore de demande de fusion. | Critère | État | |---|---| | Répond sur `127.0.0.1:5000`, injoignable de l'extérieur | ✅ éprouvé depuis un poste tiers | | Suivi dans un schéma dédié de PostgreSQL, pas en fichiers | ✅ 59 tables dans la base `mlflow`, aucun magasin fichier | | Artefacts dans le bucket `mlflow` de MinIO | ❌ **bloqué : MinIO n'est pas déployé** (#28) | | Exécution factice enregistrée puis retrouvée | ⚠️ enregistrée et retrouvée ; l'artefact échoue, l'exécution finit `FAILED` | **Le blocage** : le #28 est fusionné dans `develop` mais rien ne tourne sur le serveur — pas de conteneur MinIO, rien sur 9000/9001, pas de `/etc/enervision/minio.env`, `mc` absent. Sans bucket ni identifiants, les deux derniers critères sont hors d'atteinte. Rien à corriger de mon côté : le mandataire d'artefacts fonctionne, les `artifact_uri` sont bien en `mlflow-artifacts:/`, c'est la destination qui manque. Quand MinIO tournera, il reste vingt minutes : jouer `genere-identifiants.sh`, le contrôle de fumée, le test complet, retirer le bandeau du manuel, coller la sortie `mc ls`. <details><summary>Preuves (sorties collées du serveur)</summary> ``` $ sudo docker compose ps NAME STATUS IMAGE ev-mlflow Up 10 minutes (healthy) enervision/mlflow:3.15.2 $ sudo ss -ltnp | grep :5000 LISTEN 0 2048 127.0.0.1:5000 0.0.0.0:* users:(("python3.12",pid=1276181,fd=3),("python3.12",pid=1276180,fd=3),("python3.12",pid=1276177,fd=3)) $ curl -fsS http://127.0.0.1:5000/health OK $ psql -d mlflow -c "<tables et propriétaire>" 59 tables dans public, possédées par mlflow $ sudo docker exec ev-mlflow sh -c "ls -d /home/mlflow/mlruns 2>/dev/null || echo aucun-magasin-fichier" aucun-magasin-fichier $ sudo ps -eo args | grep "mlflow server" | head -1 /usr/local/bin/python3.12 /usr/local/bin/mlflow server --host 127.0.0.1 --port 5000 --backend-store-uri postgresql+psycopg2://mlflow@127.0.0.1:5433/mlflow --serve-artifacts --artifacts-destination s3://mlflow/ --workers 2 $ psql -d mlflow -c "<exécution factice>" experience | status | artifact_uri | params | metriques -------------------+--------+----------------------------------------------------------------+--------+----------- controle-de-fumee | FAILED | mlflow-artifacts:/1/597f5dbe0228471e9c80e8a459e0df26/artifacts | 2 | 1 controle-de-fumee | FAILED | mlflow-artifacts:/1/3bbf5d46d65242e0b68250bfbc30c458/artifacts | 2 | 1 (2 lignes) $ pytest tests/integration/test_registre_mlflow.py =========================== short test summary info ============================ FAILED tests/integration/test_registre_mlflow.py::test_l_execution_factice_est_retrouvee 1 failed, 9 passed, 4 skipped in 0.57s ``` Depuis un poste tiers de la salle, la vérification qui compte : ``` $ curl -sS --max-time 5 http://10.105.200.41:5000/health curl: (28) Connection timed out after 5004 milliseconds $ nc -z -G 5 10.105.200.41 22 -> succeeded (contre-épreuve) $ nc -z -G 5 10.105.200.41 5000 -> refusé (attendu) $ nc -z -G 5 10.105.200.41 5433 -> refusé (attendu, décision #65) ``` L'unique échec du test est le bon : il détecte précisément l'absence de MinIO. </details> ### Ce que le chantier a produit - `infra/compose/mlflow/` — image maison (base épinglée réutilisée de la chaîne), composition en réseau hôte, générateur d'identifiants, contrôle de fumée. **Aucun volume** : tout l'état est dans les deux magasins, déjà sauvegardés, et le conteneur est jetable. - `docs/runbooks/mlflow.md` — dont la promotion d'un modèle, par alias et non par « stage », qui est déprécié. - `docs/adr/0002-mlflow-mandataire-artefacts.md` — les artefacts passent **par le serveur** : les clients des #36 et #37 n'ont besoin que de `MLFLOW_TRACKING_URI`, aucun identifiant MinIO ne quitte la machine. - `tests/integration/test_registre_mlflow.py` — un cas par critère, plus le cloisonnement de l'utilisateur MinIO dédié. ### Deux défauts trouvés en le faisant tourner, et corrigés 1. `useradd --system` avec `--uid 1001` : l'image sortait sur un avertissement. 2. Plus sérieux : `MLFLOW_S3_ENDPOINT_URL` était **dans le fichier de secrets**. Fichier incomplet → variable absente → boto3 s'est rabattu sur le **vrai AWS S3**, et le client a pendu deux minutes sans qu'aucun message ne dise que la requête partait vers Internet. Une variable qui, absente, change la *cible* d'une écriture n'a pas sa place dans un fichier qu'on peut écrire à moitié : elle est passée dans la composition versionnée, avec des bornes de reprise. L'échec prend maintenant 18 s et nomme la cause. ### À savoir pour la suite - **`#36` peut déjà travailler** : paramètres, métriques et modèles enregistrés fonctionnent. Seuls les artefacts échouent. - **Ce ticket dépend du #80** pour la fusion : le manuel renvoie à la pile PostgreSQL, qui tourne sur le serveur mais dont les commits ne sont pas dans `develop` — et **le #80 n'a aucune demande de fusion ouverte**. - `/etc/enervision/mlflow.env` est écrit **à la main**, avec le seul mot de passe PostgreSQL, et porte un en-tête qui dit qu'il est incomplet. Il sera remplacé par le générateur.

olivier referenced this issue

2026-09-02 13:09:41 +00:00

[infra] Installation de MinIO, buckets du médaillon et rétention #28

olivier commented

2026-09-02 14:31:28 +00:00

Member

MinIO déployé, les quatre critères sont éprouvés — test à 14 / 14

MinIO a été mis en service dans l'après-midi (#28). J'ai enchaîné : utilisateur
MinIO dédié créé, registre redémarré, contrôle de fumée de bout en bout.

Critère	État
Le serveur répond sur `127.0.0.1:5000` et n'est pas joignable de l'extérieur	✅
Le suivi est stocké dans PostgreSQL, pas en fichiers	✅ 59 tables, possédées par le rôle `mlflow`
Les artefacts sont écrits dans le bucket `mlflow` de MinIO	✅
Une exécution factice est enregistrée puis retrouvée	✅ écrite, relue identique

Deux choses en plus des critères :

L'utilisateur MinIO dédié est cloisonné, et c'est éprouvé :
mlflow-7ffe27e5 porte la politique mlflow-artefacts, lit le bucket
mlflow et reçoit AccessDenied sur bronze, silver et gold. Le
générateur vérifie ce refus lui-même avant d'écrire le fichier de secrets,
et retire l'utilisateur s'il constate le contraire.
La section « promouvoir un modèle » du manuel a été jouée sur un modèle
jetable, supprimé ensuite : lister les versions et l'alias, comparer la
métrique, promouvoir avec les trois étiquettes (promu_par, promu_le,
promu_motif), puis retour arrière. L'alias se déplace, aucune version n'est
supprimée. Seul pyfunc.load_model reste non joué — il exige un vrai artefact
de modèle, ce sera au premier modèle du #36.

Preuves — sorties collées du serveur

$ sudo docker compose ps
NAME        STATUS                   IMAGE
ev-mlflow   Up 3 minutes (healthy)   enervision/mlflow:3.15.2

$ sudo ss -ltnp | grep :5000
LISTEN 0      2048       127.0.0.1:5000       0.0.0.0:*    users:(("python3.12",pid=1534376,fd=3),("python3.12",pid=1534375,fd=3),("python3.12",pid=1534372,fd=3))

$ psql -d mlflow -c "<tables>"
59 tables dans public, possedees par mlflow

$ sudo docker exec -i ev-mlflow python - < exemple-execution.py
Contrôle de fumée : OK
  expérience   : controle-de-fumee (id 1)
  exécution    : 5d86af005cd24163b3a22fea72a6d6ef
  artefacts    : mlflow-artifacts:/1/5d86af005cd24163b3a22fea72a6d6ef/artifacts
  artefact relu : temoin.txt, 60 octets, identique

À retrouver dans l'interface, puis à prouver côté stockage :
  mc ls --recursive local/mlflow/1/

$ mc ls --recursive local/mlflow/   (identifiants racine)
[2026-09-02 14:26:01 UTC]    62B STANDARD 1/325491b2b6cf47679d03746625d85e30/artifacts/temoin.txt
[2026-09-02 14:26:51 UTC]    62B STANDARD 1/46989f25cdbb4395b26cd97792a517e8/artifacts/temoin.txt
[2026-09-02 14:29:44 UTC]    62B STANDARD 1/5d86af005cd24163b3a22fea72a6d6ef/artifacts/temoin.txt
[2026-09-02 14:25:19 UTC]    62B STANDARD 1/78c9b63010724f24b97f3cb5dec57823/artifacts/temoin.txt

$ avec les identifiants DEDIES du registre
identifiant : mlflow-7ffe27e5
[2026-09-02 14:26:01 UTC]    62B STANDARD 1/325491b2b6cf47679d03746625d85e30/artifacts/temoin.txt
[2026-09-02 14:26:51 UTC]    62B STANDARD 1/46989f25cdbb4395b26cd97792a517e8/artifacts/temoin.txt
[2026-09-02 14:29:44 UTC]    62B STANDARD 1/5d86af005cd24163b3a22fea72a6d6ef/artifacts/temoin.txt
  bronze : AccessDenied (attendu)
  silver : AccessDenied (attendu)
  gold : AccessDenied (attendu)

$ mc admin user info local <identifiant>
mc: <ERROR> Unable to get user info. Invalid arguments specified. (Invalid arguments specified).

$ nettoyage du fichier de secrets provisoire
mlflow.env.ancien effacé
600 root:root /etc/enervision/mlflow.env

$ pytest tests/integration/test_registre_mlflow.py
..............                                                           [100%]
14 passed in 0.67s

$ mc admin user info local mlflow-7ffe27e5
AccessKey: mlflow-7ffe27e5
Status: enabled
PolicyName: mlflow-artefacts
MemberOf: []

ENF-14, depuis un poste tiers de la salle :

$ depuis un poste tiers de la salle (mon poste)
$ curl -sS --max-time 5 http://10.105.200.41:5000/health  -> curl: (28) Connection timed out after 5006 milliseconds
$ nc -z 10.105.200.41 22    -> ouvert
$ nc -z 10.105.200.41 5000  -> refusé
$ nc -z 10.105.200.41 5433  -> refusé
$ nc -z 10.105.200.41 9000  -> refusé
$ nc -z 10.105.200.41 9001  -> refusé

Trois défauts trouvés en installant, et corrigés

useradd --system avec --uid 1001 : l'image sortait sur un avertissement.
MLFLOW_S3_ENDPOINT_URL était dans le fichier de secrets. Fichier
incomplet → variable absente → boto3 se rabat sur le vrai AWS S3, et le
client attend deux minutes sans qu'aucun message ne dise que la requête part
vers Internet. Une variable qui, absente, change la cible d'une écriture n'a
pas sa place dans un fichier qu'on peut écrire à moitié : elle est passée dans
la composition versionnée, avec des bornes de reprise. L'échec prend
maintenant 18 s et nomme la cause.
Mon test prenait une exécution sans ordonner. L'expérience garde
l'historique de ses échecs : le cas passait ou échouait selon l'exécution que
l'API choisissait. Il regarde maintenant la dernière, explicitement.

Ce qui a changé sur le serveur, et qui n'est pas à moi

Le client mc a été installé en /usr/local/bin/mc
(RELEASE.2025-08-13T08-35-41Z), par la commande de
docs/runbooks/stockage-minio.md. Il n'était pas là et
genere-identifiants.sh en dépend.
Le réseau bridge de Docker fonctionne sur ce LXC, contrairement au constat
du journal du 31 août : MinIO tourne en bridge, ports publiés sur 127.0.0.1,
et rien ne répond depuis la salle. Cette pile-ci reste en réseau hôte pour une
autre raison, qui n'a pas bougé — elle doit joindre les deux magasins sur la
boucle locale de l'hôte.
/etc/enervision/minio.env est en 640 root:deploy, là où le #28 et son test
attendent 600 root. Signalé là-bas, pas corrigé ici.

Reste à faire

Le manuel n'a plus de bandeau d'avertissement et porte son historique. Ce
ticket dépend du #80 pour la fusion : le manuel renvoie à la pile PostgreSQL,
qui tourne sur le serveur mais dont les commits ne sont pas dans develop — et
le #80 n'a toujours aucune demande de fusion ouverte.

#36 peut commencer : export MLFLOW_TRACKING_URI=http://127.0.0.1:5000, et
rien d'autre. Aucun identifiant MinIO à copier sur la machine du T4.

### MinIO déployé, les quatre critères sont éprouvés — test à 14 / 14 MinIO a été mis en service dans l'après-midi (#28). J'ai enchaîné : utilisateur MinIO dédié créé, registre redémarré, contrôle de fumée de bout en bout. | Critère | État | |---|---| | Le serveur répond sur `127.0.0.1:5000` et n'est pas joignable de l'extérieur | ✅ | | Le suivi est stocké dans PostgreSQL, pas en fichiers | ✅ 59 tables, possédées par le rôle `mlflow` | | Les artefacts sont écrits dans le bucket `mlflow` de MinIO | ✅ | | Une exécution factice est enregistrée puis retrouvée | ✅ écrite, relue identique | Deux choses en plus des critères : - **L'utilisateur MinIO dédié est cloisonné, et c'est éprouvé** : `mlflow-7ffe27e5` porte la politique `mlflow-artefacts`, lit le bucket `mlflow` et reçoit `AccessDenied` sur `bronze`, `silver` et `gold`. Le générateur vérifie ce refus lui-même **avant** d'écrire le fichier de secrets, et retire l'utilisateur s'il constate le contraire. - **La section « promouvoir un modèle » du manuel a été jouée** sur un modèle jetable, supprimé ensuite : lister les versions et l'alias, comparer la métrique, promouvoir avec les trois étiquettes (`promu_par`, `promu_le`, `promu_motif`), puis retour arrière. L'alias se déplace, aucune version n'est supprimée. Seul `pyfunc.load_model` reste non joué — il exige un vrai artefact de modèle, ce sera au premier modèle du #36. <details><summary>Preuves — sorties collées du serveur</summary> ``` $ sudo docker compose ps NAME STATUS IMAGE ev-mlflow Up 3 minutes (healthy) enervision/mlflow:3.15.2 $ sudo ss -ltnp | grep :5000 LISTEN 0 2048 127.0.0.1:5000 0.0.0.0:* users:(("python3.12",pid=1534376,fd=3),("python3.12",pid=1534375,fd=3),("python3.12",pid=1534372,fd=3)) $ psql -d mlflow -c "<tables>" 59 tables dans public, possedees par mlflow $ sudo docker exec -i ev-mlflow python - < exemple-execution.py Contrôle de fumée : OK expérience : controle-de-fumee (id 1) exécution : 5d86af005cd24163b3a22fea72a6d6ef artefacts : mlflow-artifacts:/1/5d86af005cd24163b3a22fea72a6d6ef/artifacts artefact relu : temoin.txt, 60 octets, identique À retrouver dans l'interface, puis à prouver côté stockage : mc ls --recursive local/mlflow/1/ $ mc ls --recursive local/mlflow/ (identifiants racine) [2026-09-02 14:26:01 UTC] 62B STANDARD 1/325491b2b6cf47679d03746625d85e30/artifacts/temoin.txt [2026-09-02 14:26:51 UTC] 62B STANDARD 1/46989f25cdbb4395b26cd97792a517e8/artifacts/temoin.txt [2026-09-02 14:29:44 UTC] 62B STANDARD 1/5d86af005cd24163b3a22fea72a6d6ef/artifacts/temoin.txt [2026-09-02 14:25:19 UTC] 62B STANDARD 1/78c9b63010724f24b97f3cb5dec57823/artifacts/temoin.txt $ avec les identifiants DEDIES du registre identifiant : mlflow-7ffe27e5 [2026-09-02 14:26:01 UTC] 62B STANDARD 1/325491b2b6cf47679d03746625d85e30/artifacts/temoin.txt [2026-09-02 14:26:51 UTC] 62B STANDARD 1/46989f25cdbb4395b26cd97792a517e8/artifacts/temoin.txt [2026-09-02 14:29:44 UTC] 62B STANDARD 1/5d86af005cd24163b3a22fea72a6d6ef/artifacts/temoin.txt bronze : AccessDenied (attendu) silver : AccessDenied (attendu) gold : AccessDenied (attendu) $ mc admin user info local <identifiant> mc: <ERROR> Unable to get user info. Invalid arguments specified. (Invalid arguments specified). $ nettoyage du fichier de secrets provisoire mlflow.env.ancien effacé 600 root:root /etc/enervision/mlflow.env $ pytest tests/integration/test_registre_mlflow.py .............. [100%] 14 passed in 0.67s ``` ``` $ mc admin user info local mlflow-7ffe27e5 AccessKey: mlflow-7ffe27e5 Status: enabled PolicyName: mlflow-artefacts MemberOf: [] ``` ENF-14, depuis un poste tiers de la salle : ``` $ depuis un poste tiers de la salle (mon poste) $ curl -sS --max-time 5 http://10.105.200.41:5000/health -> curl: (28) Connection timed out after 5006 milliseconds $ nc -z 10.105.200.41 22 -> ouvert $ nc -z 10.105.200.41 5000 -> refusé $ nc -z 10.105.200.41 5433 -> refusé $ nc -z 10.105.200.41 9000 -> refusé $ nc -z 10.105.200.41 9001 -> refusé ``` </details> ### Trois défauts trouvés en installant, et corrigés 1. `useradd --system` avec `--uid 1001` : l'image sortait sur un avertissement. 2. **`MLFLOW_S3_ENDPOINT_URL` était dans le fichier de secrets.** Fichier incomplet → variable absente → boto3 se rabat sur le **vrai AWS S3**, et le client attend deux minutes sans qu'aucun message ne dise que la requête part vers Internet. Une variable qui, absente, change la *cible* d'une écriture n'a pas sa place dans un fichier qu'on peut écrire à moitié : elle est passée dans la composition versionnée, avec des bornes de reprise. L'échec prend maintenant 18 s et nomme la cause. 3. Mon test prenait une exécution **sans ordonner**. L'expérience garde l'historique de ses échecs : le cas passait ou échouait selon l'exécution que l'API choisissait. Il regarde maintenant la dernière, explicitement. ### Ce qui a changé sur le serveur, et qui n'est pas à moi - **Le client `mc` a été installé** en `/usr/local/bin/mc` (`RELEASE.2025-08-13T08-35-41Z`), par la commande de `docs/runbooks/stockage-minio.md`. Il n'était pas là et `genere-identifiants.sh` en dépend. - **Le réseau bridge de Docker fonctionne sur ce LXC**, contrairement au constat du journal du 31 août : MinIO tourne en bridge, ports publiés sur `127.0.0.1`, et rien ne répond depuis la salle. Cette pile-ci reste en réseau hôte pour une autre raison, qui n'a pas bougé — elle doit joindre les deux magasins sur la boucle locale de l'**hôte**. - `/etc/enervision/minio.env` est en `640 root:deploy`, là où le #28 et son test attendent `600 root`. Signalé là-bas, pas corrigé ici. ### Reste à faire Le manuel n'a plus de bandeau d'avertissement et porte son historique. **Ce ticket dépend du #80 pour la fusion** : le manuel renvoie à la pile PostgreSQL, qui tourne sur le serveur mais dont les commits ne sont pas dans `develop` — et le #80 n'a toujours aucune demande de fusion ouverte. `#36` peut commencer : `export MLFLOW_TRACKING_URI=http://127.0.0.1:5000`, et rien d'autre. Aucun identifiant MinIO à copier sur la machine du T4.

olivier referenced this issue

2026-09-02 14:31:56 +00:00

[infra] Installation de MinIO, buckets du médaillon et rétention #28

olivier referenced this issue from a commit

2026-09-03 07:57:18 +00:00

infra: pose le registre de modèles MLflow sur PostgreSQL et MinIO

olivier referenced this issue from a pull request that will close it,

2026-09-03 07:58:29 +00:00

infra: pose le registre de modèles MLflow sur PostgreSQL et MinIO #100

lenaic closed this issue

2026-09-03 08:06:14 +00:00

lenaic referenced this issue