Registre arrets: première automatisation

[ptitfred]

Automatise le registre d'arrêt brut fait dans #4393. Voir l'epic #4354.

• un module Transport.S3.AggregatesUploader responsable de l'upload sur S3 d'un fichier, l'upload de son sha256 dans un fichier voisin, et la mise à jour d'un fichier "latest" avec cette dernière version. A cette occasion un bucket dédié est alloué : transport-data-gouv-fr-aggregates-{prod|staging|dev|test}.
• un nouveau job Transport.Jobs.StopsRegistrySnapshot qui chaine l'extraction de registre d'arrêt et l'upload S3. Ce job est quotidien à 4h du matin UTC.

Notes de design

L'uploader Transport.S3.AggregatesUploader est fait pour être réutilisé, notamment par l'extracteur IRVE. Pour l'instant il ne supporte l'upload que d'un fichier, mais on peut le généraliser à une énumération.

L'algorithme de hash est hardcodé à sha256 pour l'instant. On pourrait aisément le rendre configurable et/ou optionnel si nécessaire.

Le job du registre d'arrêt est tellement simple qu'écrire un test pour celui-ci serait à mon avis artificiellement compliqué (nécessiterait notamment de fournir des stubs sur le registre d'arrêt et le helper d'upload). Ca semble assez artificiel.

[thbar]

Je vais faire un petit test en local pour bien ingérer le fonctionnement, et je reviens reviewer.

[thbar]

J'ai pu faire un test en local qui s'est bien passé (avec MinIO) 🎉

⚠️ Si je comprends bien, il faudra créer les buckets sur la recette et la production !

J'ai mis quelques remarques côté code (plutôt des ajustements).

Sur le plus long terme (hors de cette PR) je me suis dit que le code bas niveau pourrait gagner à être rendu plus composable / découplé (ex: une fonction qui fait l'upload, avec une option pour calculer le checksum, appelée une fois par fichier concerné par l'appelant, au lieu d'une fonction qui fixe le scénario "latest + historisé" elle-même), mais c'est secondaire pour le moment et on verra si ça apparaît comme besoin.

[ptitfred]

⚠️ Si je comprends bien, il faudra créer les buckets sur la recette et la production !

Pas besoin, chez clever c'est automatique.

[ptitfred]

Sur le plus long terme (hors de cette PR) je me suis dit que le code bas niveau pourrait gagner à être rendu plus composable / découplé (ex: une fonction qui fait l'upload, avec une option pour calculer le checksum, appelée une fois par fichier concerné par l'appelant, au lieu d'une fonction qui fixe le scénario "latest + historisé" elle-même), mais c'est secondaire pour le moment et on verra si ça apparaît comme besoin.

Ouais clairement, et d'ailleurs l'avoir fait au même endroit m'a pas aidé à tester le tout. Ca me démange fort de découper.

[ptitfred]

Je bougerai pas le calcul du hash dans cette PR.

@thbar note qu'actuellement ça uploade sur le bucket avec des acl privées. Je n'ai pas creusé cet aspect.

[thbar]

Je bougerai pas le calcul du hash dans cette PR.

Aucun souci, c'était juste une pensée plutôt qu'une attente.

@thbar note qu'actuellement ça uploade sur le bucket avec des acl privées. Je n'ai pas creusé cet aspect.

Alors ça m'arrange, je me posais la question d'avoir des statistiques bien fiables via le proxy, et de comment éviter un téléchargement "par le côté", alors ça me va. Ça amène d'autres points mais on pourra voir plus tard.

[thbar]

Top, merci @ptitfred

[thbar]

@ptitfred je te laisse merger à un moment qui te va ?

[ptitfred]

Pas besoin, chez clever c'est automatique.

J'ai menti. Je pensais l'avoir observé en faisant mes tests en local, mais c'est peut-être une conséquence d'avoir testé avec un outil tiers (s3cmd).

Je les ai créés à la main donc (prod, staging, et dev).

[thbar]

Je les ai créés à la main donc (prod, staging, et dev).

Top, merci !