Projet

Général

Profil

Development #56595

permettre de désactiver les cron sur un tenant particulier

Ajouté par Thomas Noël il y a plus de 2 ans. Mis à jour il y a plus de 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
02 septembre 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

Lié à w.c.s. - Development #56597: permettre de couper les cron sur une instanceFermé02 septembre 2021

Actions

Révisions associées

Révision f9de8f6f (diff)
Ajouté par Emmanuel Cazenave il y a plus de 2 ans

multitenant: enable DISABLE_CRON_JOBS for a specific tenant (#56595)

Historique

#1

Mis à jour par Thomas Noël il y a plus de 2 ans

#2

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) ?

#3

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).

#4

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).

#5

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 :)

#6

Mis à jour par Emmanuel Cazenave il y a plus de 2 ans

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Emmanuel Cazenave
#7

Mis à jour par Emmanuel Cazenave il y a plus de 2 ans

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.

#8

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

  • Statut changé de Solution proposée à Solution validée
#9

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:

#10

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 ?

#11

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)

#12

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é.

#13

Mis à jour par Emmanuel Cazenave il y a plus de 2 ans

Voilà, j'ai même mis un 'WARNING' pour attirer l'attention dans le cas --force-job.

#14

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.

#15

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)
#16

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

Formats disponibles : Atom PDF