Attentes de configuration S3 entre les paramètres globaux et ceux du site

Dev
1

J’ai une instance Discourse où, plusieurs mois après sa création initiale, nous avons activé « S3 » (dans notre cas, DigitalOcean Spaces) pendant un certain temps, uniquement via les paramètres d’administration et jamais avec des options de configuration DISCOURSE_ dans le fichier app.yml. Nous n’avons jamais migré l’intégralité des données vers S3, mais la majorité de nos images ont été écrites alors que cette option était activée. Nous souhaitons maintenant tout migrer hors de « S3 » pour diverses raisons qui ne sont pas importantes ici.

(Je sais que cela ressemble à une demande d’assistance pour l’instant. Mais ce n’est pas le cas…)

Dans une PR récemment fusionnée, j’ai ajouté une tâche Rake uploads:batch_migrate_from_s3 comme un simple wrapper autour de uploads:migrate_from_s3 afin de pouvoir migrer des lots aussi petits que les images d’un seul post, et je l’ai exécutée. À ce stade, j’ai découvert que upload:migrate_from_s3, que ma tâche appelle, suppose que discourse.conf contient des paramètres S3 qui ne sont pas disponibles dans l’interface utilisateur :

** Invoke uploads:batch_migrate_from_s3 (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute uploads:batch_migrate_from_s3
Migrating uploads from S3 to local storage for 'default'...
rake aborted!
NoMethodError: undefined method `downcase' for nil:NilClass
/var/www/discourse/app/models/global_setting.rb:107:in `s3_bucket_name'
/var/www/discourse/app/models/site_setting.rb:157:in `absolute_base_url'
/var/www/discourse/lib/tasks/uploads.rake:138:in `migrate_from_s3'
/var/www/discourse/lib/tasks/uploads.rake:118:in `block in migrate_all_from_s3'

Quelle est la meilleure solution ?

  1. Il est attendu que la configuration S3 soit toujours effectuée via des variables d’environnement DISCOURSE_ dans le fichier app.yml et écrites dans config/discourse.conf lors de la construction du conteneur, et je devrais le faire et reconstruire mon application maintenant. (Je note que l’entrée de variable d’environnement pour Rake ne semble pas définir GlobalSettings ici non plus ; j’ai essayé cela aussi. Apparemment, le fait que quoi que ce soit fonctionne avec uniquement SiteSettings configuré est une oversight et non intentionnel.) J’ai testé cela en ajoutant s3_bucket dans mon config/discourse.conf dans mon conteneur existant, et cela a résolu l’erreur pour moi.
  2. Modifier davantage la tâche de migration afin que, si SiteSetting.s3_upload_bucket est défini mais que GlobalSetting.s3_bucket est nil, on affecte GlobalSetting.s3_bucket à SiteSetting.s3_upload_bucket — je suppose que ce ne serait pas un PR difficile si cela est considéré comme correct, mais je n’ai pas encore regardé de près. Édito : J’ai essayé de modifier GlobalSetting.s3_bucket dans uploads:migrate_from_s3 et cela n’a pas fonctionné à cause de l’absence d’un accesseur.
  3. Faire en sorte que SiteSetting.absolute_base_url utilise SiteSetting.s3_upload_bucket si GlobalSetting.s3_bucket est nil — est-ce même une configuration prévue ?
  4. Ajouter la possibilité de définir s3_bucket dans les paramètres du site afin qu’il soit exposé dans l’interface utilisateur.

La première option relève simplement de la configuration du site, et je vais probablement juste le faire. Si la deuxième est considérée comme une bonne alternative, je suis heureux de tenter un PR. Cependant, je suis encore assez nouveau ici pour ne pas être confiant dans la réalisation de modifications aussi fondamentales que les deux dernières ; les attentes concernant le fonctionnement des objets de configuration sont un peu opaques pour moi.

Pour être clair : j’ai contourné trivialement mon problème ; cela m’a simplement surpris que cela soit nécessaire.

2 « J'aime »
Rake uploads:migrate_from_s3 fails
Rake uploads:migrate_from_s3 fails