@zogstrip, pourrais-tu passer en revue cette PR, puisque tu as le contexte de la dernière revue que j’ai faite dans ce domaine ? FIX: Make migrations from S3 more robust; fix bare URL migration by johnsonm · Pull Request #10093 · discourse/discourse · GitHub
J’y ai inclus les correctifs que j’ai appliqués pendant l’exécution de cette migration relativement importante. Je n’ai pas essayé d’ajouter des tests pour chaque correctif ; je ne suis pas sûr de savoir comment injecter chaque type d’erreur. Mais au moins, la nouvelle fonctionnalité est testée.
@RGJ, je pense que ma PR, telle qu’elle est actuellement, pourrait résoudre tous vos points sauf les deux premiers, sauf que je ne suis pas sûr concernant le CDN. Mon site utilisait un CDN et a migré des vidéos ayant des URL CDN, mais cela aurait pu être un effet secondaire du nommage avec les espaces Discourse. Si vous avez d’autres cas, j’espère que ma PR vous fournira une base facile pour ajouter des variantes au regex et créer des cas de test supplémentaires.
Je pense qu’il est logique de migrer d’abord par publication, car après avoir migré les pièces jointes d’une publication, celle-ci doit être rebouclée afin que la version cuite contienne les bonnes URL. Une fois que j’aurai terminé la migration de mes publications (ce qui pourrait prendre moins de deux semaines maintenant que j’ai modifié ma limitation de débit pour vérifier directement la longueur de la file d’attente), je m’attacherai aux travaux restants à effectuer pour nettoyer.
Comme plusieurs publications peuvent partager des références au même contenu si plus d’une personne télécharge le même fichier, il faut une deuxième passe qui vérifie les données cuites pour détecter d’anciennes URL et reboucler ces publications afin d’adopter les nouvelles emplacements. Cela peut utiliser la même limitation de débit pour éviter de saturer les files d’attente.
Je ne devrais probablement voir aucun logo cassé sur makerforums, car nous avons ajusté la marque après avoir cessé de mettre du nouveau contenu dans « s3 » (pour nous, DigitalOcean Spaces), mais je verrai probablement encore beaucoup de pièces jointes stockées dans S3, au moins pour les avatars. La migration des pièces jointes non associées à une publication ne devrait être lancée qu’après la migration de toutes les publications, et je devrai probablement rédiger cela une fois que j’aurai terminé la migration des pièces jointes dans les publications.
@pfaffman, je vois Bizarre Problems with migrate_from_s3 - #5 qui décrit des erreurs qui ne se sont pas reproduites. Sans mes correctifs dans la PR actuelle, les erreurs sont ignorées silencieusement, y compris les échecs de validation. Je pense que le travail ici résoudra au moins certains des problèmes que vous avez rencontrés à l’époque.
@hosna, les problèmes que vous soulevez dans https://meta.discourse.org/t/what-does-rake-uploads-migrate-from-s3-exactly-do/97285 sont soit partiellement, soit complètement résolus pour l’instant dans cette PR. S’ils ne sont pas complètement résolus, j’ai ajouté des tests qui faciliteront l’ajout de tests supplémentaires pour valider d’autres correctifs.
@sam, puisque vous avez ajouté l’étiquette 2.6 à la PR, je suppose qu’elle ne sera pas fusionnée avant au moins quelques jours ; devrais-je intégrer mon travail sur la fonctionnalité de limitation de débit dans la PR avec les correctifs ? Ou préférez-vous garder les correctifs et le travail sur les fonctionnalités dans des PR séparées ? Je peux faire les deux. La fonctionnalité de limitation de débit fonctionne très bien ; je migre environ trois fois plus vite, sans impact sur la disponibilité du site, maintenant que j’attends que la file d’attente Sidekiq se vide, donc il semble logique de l’intégrer, si c’est quelque chose qui est normalement accepté dans les PR. Sinon, je dois attendre que la PR soit fusionnée pour le travail sur lequel elle se base, donc dans les deux cas, il serait bon d’avoir votre avis.
..
J’ai factorisé mon correctif de limitation de débit de migration et l’ai intégré à la PR. Cela fonctionne en pratique, et sar indique que je vois presque zéro temps d’inactivité en continu, tandis que le site continue de fonctionner, pendant la migration en direct. Un avantage du mode par lots est que je peux vérifier la disponibilité de nouvelles versions de Discourse après chaque lot complet de migrations ; j’ai mis à jour mon site vers la version 2.6.0beta1 dès que possible après sa sortie, et j’exécute les migrations avec succès sur 2.6.0beta1 avec ma PR de migration au-dessus depuis la mise à jour.
Je pense que la PR est prête pour la revue ; je prévois de soumettre une autre PR pour les dernières étapes, mais la mise en place de celle-ci améliorera l’expérience de migration générale pour tous, même avant que je n’achève les dernières parties.