Development #56595
permettre de désactiver les cron sur un tenant particulier
0%
Description
On voudrait pouvoir couper tous les cron d'un Publik le temps d'une action particulièrement délicate, par exemple une migration, ou même un gros bogue qui plante des dizaines de demandes, ...
Actuellement il existe une possibilité de settings.DISABLE_CRON_JOBS qui, s'il est True, va faire qu'une commande de manage avec tenant_schema --all-tenants
ne sera pas exécutée -- car on considère que c'est un cron.
Mais ce settings est général à tous les tenants. Il est prévu pour ne laisser tourner les cron que sur un node1 et les bloquer sur node2 dans le cas d'un hébergement en balance de charge, afin d'éviter que des actions se marchent sur les pieds.
Ce ticket est pour demander la possibilité de couper l'exécution des cron uniquement pour un tenant donné.
On utiliserait le même DISABLE_CRON_JOBS mais dans le settings.json du tenant. Notons que ça permettrait juste de couper les cron d'un node qui les exécute : si on met False mais que le settings général est True, alors ça n'activera pas les cron du tenant...
Idéalement, possibilité de régler ce DISABLE_CRON_JOBS via un SettingsLoader afin de taper dans tous les services cibles d'un seul Publik (or wcs à jouer à part) -- mais peut-être que SettingsVars pourrait déjà faire l'affaire ? (et donc juste documenter qu'il faut poser SETTING_DISABLE_CRON_JOBS=True, sans oublier de remettre SETTING_DISABLE_CRON_JOBS=False pour l'annuler ensuite)
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Thomas Noël il y a plus de 2 ans
- Lié à Development #56597: permettre de couper les cron sur une instance ajouté
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
genre touch /var/lib/truc/tenants/machin.clapotis-les-canards.fr/disable_cron
et ça coupe pendant 12h après mtime (genre si on l'oublie c'est pas bien grave) ?
Mis à jour par Thomas Noël il y a plus de 2 ans
Benjamin Dauvergne a écrit :
genre
touch /var/lib/truc/tenants/machin.clapotis-les-canards.fr/disable_cron
et ça coupe pendant 12h après mtime (genre si on l'oublie c'est pas bien grave) ?
Why not mais je préfère mon idée d'un settings envoyé à tous les logiciels d'un Publik, pour couper complètement les cron d'une instance. Par ailleurs je préfère éviter de relancer les cron automatiquement 12h après. Parce qu'un des cas d'usage que j'imagine c'est, de permettre l'accès https à une ex-instance (migrée ailleurs), en sachant qu'elle "ne bouge plus" (une fois coupé l'accès au formulaires en front, les inscriptions, voire les envois de mails wcs).
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Thomas Noël a écrit :
Why not mais je préfère mon idée d'un settings envoyé à tous les logiciels d'un Publik, pour couper complètement les cron d'une instance. Par ailleurs je préfère éviter de relancer les cron automatiquement 12h après. Parce qu'un des cas d'usage que j'imagine c'est, de permettre l'accès https à une ex-instance (migrée ailleurs), en sachant qu'elle "ne bouge plus" (une fois coupé l'accès au formulaires en front, les inscriptions, voire les envois de mails wcs).
Oui parfait, penser à une intégration hobo aussi alors (je ne sais où dans l'interface, peut-être directement sur la page des services).
Mis à jour par Thomas Noël il y a plus de 2 ans
Benjamin Dauvergne a écrit :
Thomas Noël a écrit :
Why not mais je préfère mon idée d'un settings envoyé à tous les logiciels d'un Publik, pour couper complètement les cron d'une instance. Par ailleurs je préfère éviter de relancer les cron automatiquement 12h après. Parce qu'un des cas d'usage que j'imagine c'est, de permettre l'accès https à une ex-instance (migrée ailleurs), en sachant qu'elle "ne bouge plus" (une fois coupé l'accès au formulaires en front, les inscriptions, voire les envois de mails wcs).
Oui parfait, penser à une intégration hobo aussi alors (je ne sais où dans l'interface, peut-être directement sur la page des services).
Oui, dans un premier temps je pense qu'on peut poser un "SETTING_DISABLE_CRON_JOBS" dans les variables de l'instance et hop, ça diffuse. Ensuite on pourrait imaginer une petite UI spécifique dans Hobo, notamment pour mettre un message en rouge quand c'est à True :)
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Statut changé de Nouveau à En cours
- Assigné à mis à Emmanuel Cazenave
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Fichier 0001-multitenant-enable-DISABLE_CRON_JOBS-for-a-specific-.patch 0001-multitenant-enable-DISABLE_CRON_JOBS-for-a-specific-.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
Trois plombes pour comprendre qu'il faut commencer le tests par settings.clear_tenants_settings()
sinon ça se marche sur les pieds avec d'autres.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Thomas Noël il y a plus de 2 ans
- Statut changé de Solution validée à Solution proposée
Je me permet de retirer le ack, car je suis un peu embêté par :
if not args_namespace.force_job and getattr(settings, 'DISABLE_CRON_JOBS', False):
pour moi, le --force-job --all-tenant devrait permettre de forcer un job sur tous les tenants si DISABLE_CRON_JOBS est vrai en général, sauf sur les tenants explicitement avec DISABLE_CRON_JOBS vrai (ie ceux qu'on veut "totalement freezer"). Pour ces tenants là, afficher le warning et si vraiment il faut lancer une commande, alors l'adminsys pourra la lancer spécifiquement sur le/les tenants freezes. Bref, avoir juste if getattr(settings, 'DISABLE_CRON_JOBS', False):
.
Et forcer l'affichage du warning dans ce cas avec if args_verbosity.verbosity > 1 or args_namespace.force_job:
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
Ce serait quand même plus simple/mieux mémorisable que --force-job permette de forcer quelque soit le niveau où ait été posé le DISABLE_CRON_JOBS. Là il faudra se souvenir que ça force dans un cas mais pas dans l'autre .... c'est confus.
Aussi j'ai l'impression qu'on résonne sur un truc qui n'est de toute façon jamais utilisé (--force-job), je n'en trouve pas trace dans nos dépôts (packaging + puppet), est-ce que quelqu'un s'est déjà servi de --force-job ?
Mis à jour par Frédéric Péters il y a plus de 2 ans
est-ce que quelqu'un s'est déjà servi de --force-job ?
(oui)
Mis à jour par Thomas Noël il y a plus de 2 ans
Emmanuel Cazenave a écrit :
Ce serait quand même plus simple/mieux mémorisable que --force-job permette de forcer quelque soit le niveau où ait été posé le DISABLE_CRON_JOBS. Là il faudra se souvenir que ça force dans un cas mais pas dans l'autre .... c'est confus.
Aussi j'ai l'impression qu'on résonne sur un truc qui n'est de toute façon jamais utilisé (--force-job), je n'en trouve pas trace dans nos dépôts (packaging + puppet), est-ce que quelqu'un s'est déjà servi de --force-job ?
Oui, pour lancer un truc sur node2 (qui a DISABLE_CRON_JOBS=True), et c'est toujours à la main (jamais puppet ou autre). Et justement comme on n'a pas trop l'habitude, le jour où, ça serait bien que le job ne soit pas forcé sur les tenants explicitement coupés. Et en faisant un "print" pour rappeler que tel et tel tenant a été sauté parce que explicitement coupé.
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Fichier 0001-multitenant-enable-DISABLE_CRON_JOBS-for-a-specific-.patch 0001-multitenant-enable-DISABLE_CRON_JOBS-for-a-specific-.patch ajouté
Voilà, j'ai même mis un 'WARNING' pour attirer l'attention dans le cas --force-job.
Mis à jour par Thomas Noël il y a plus de 2 ans
<modegrorelou>Retirer l'espace avant les deux points dans "WARNING :"</modegrorelou> et ça roule.
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Statut changé de Solution proposée à Résolu (à déployer)
commit f9de8f6f6d00065075c4a426d637d5c80755577d Author: Emmanuel Cazenave <ecazenave@entrouvert.com> Date: Thu Sep 9 12:40:56 2021 +0200 multitenant: enable DISABLE_CRON_JOBS for a specific tenant (#56595)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
multitenant: enable DISABLE_CRON_JOBS for a specific tenant (#56595)