Produits Entr'ouvert » Hobo

• soit des options de migrate_schema, soit une nouvelle commande dédiée pour ne pas tout mélanger
• permettre de passer un nombre de processus max en ligne de commande, ou dans les settings, sinon par défaut nombre de coeurs
• utilisation de https://docs.python.org/2/library/multiprocessing.html (imap_unordered)
• si possible permettre le démarrage «dès que possible» des workers uwsgi :
  • préparer la migration en posant un "on-maintenance.lock" sur tous tenants
  • avoir un retour 503 dans hobo.multitenant.middleware.TenantMiddleware sur un tenant tant que ce lock existe, cela "ferme" le tenant
  • quand la migration d'un tenant est terminée, libérer le lock (ie supprimer le fichier), le middleware fait alors son boulot normal, le tenant est ouvert
  • ça demande que cette commande manage de migration rende la main aussitôt que les locks sont posés, et travaille en tâche de fond, laissant le lancement de uwsgi se faire, qui attendra la libération des tenants un par un
  • étudier au passage comment NE PAS lancer les cron sur les tenants lockés (voire, autre sujet, quand le serveur uwsgi n'est pas lancé)

Thomas Noël a écrit :

• étudier au passage comment NE PAS lancer les cron sur les tenants lockés (voire, autre sujet, quand le serveur uwsgi n'est pas lancé)

Je me dis qu'on pourrait utiliser des locks explicites postgres plutôt que de passer par le FS (et ça résoud le problème quand on a plusieurs front en plus): https://www.postgresql.org/docs/9.4/static/explicit-locking.html

Thomas Noël a écrit :

• ça demande que cette commande manage de migration rende la main aussitôt que les locks sont posés, et travaille en tâche de fond, laissant le lancement de uwsgi se faire, qui attendra la libération des tenants un par un
• étudier au passage comment NE PAS lancer les cron sur les tenants lockés (voire, autre sujet, quand le serveur uwsgi n'est pas lancé)

• ajout de tables ou de colonnes
• suppressions de tables ou de colonnes

• appliquer les ajouts
• relancer les serveurs et les crons sur le nouveau code
• appliquer les suppressions

Dans cet ordre là il n'est pas nécessaire de locker tout peut se faire en parallèle, il peut y avoir un peu de contention entre les migrations et le code de l'application (cron ou uwsg) mais nos migrations étant généralement assez courtes je ne crois pas qu'on ait des contentions importantes.

À voir comment on pourrait automatiser ce fonctionnement.

Benjamin Dauvergne a écrit :

En fait on aurait rien besoin de locker si on s'astreignait à une certain discipline car il y a deux types de migrations :

• ajout de tables ou de colonnes
• suppressions de tables ou de colonnes

Je pense qu'il y a aussi les renommages (sans doute à gérer en premier) et sans doute d'autres choses encore. Mais je n'arrive pas à voir comment on peut séparer les choses dans Django sauf à mettre les doigts dans le code de migration. Ou bien je rate qqchose ?

C'est peut-être nouveau de django-tenant-schemas mais je vois maintenant tenant_schemas/migration_executors/parallel.py et dans ce fichier :

    def run_tenant_migrations(self, tenants):
        if tenants:
            processes = getattr(settings, 'TENANT_PARALLEL_MIGRATION_MAX_PROCESSES', 2)
            chunks = getattr(settings, 'TENANT_PARALLEL_MIGRATION_CHUNKS', 2)

Pas si nouveau (mars 2007 https://github.com/bernardopires/django-tenant-schemas/commit/323cfcd38a60d61a9ba9b96eb01fa4a9a2e30d82) et c'est dispo sur nos prod.

2017. Et du coup chez nous ça a fait partie de #18178.