Development #50017
utiliser le spooler uwsgi pour l'exécution des jobs
0%
Description
Comme ça a été fait dans #48407 pour w.c.s.; ça aurait notamment comme avantage d'éviter un délai de max 5 minutes avant l'exécution.
Files
History
Updated by Lauréline Guerin 12 days ago
- Patch proposed changed from No to Yes
- Status changed from Nouveau to En cours
- File 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch added
à discuter
je pense qu'il manque quelque chose dans le spooler pour passer le domain:
subprocess.run([ settings.PASSERELLE_MANAGE_COMMAND, 'runjob', '--job-id', args['job_id'] ])
mais je ne vois pas d'exemple dans le code
à la différence de wcs qui lance des jobs pendant le rendering de la réponse via un middleware, je me suis dit qu'on pouvait se placer dans le add_job:
def add_job(self, method_name, natural_id=None, after_timestamp=None, **kwargs): resource_type = ContentType.objects.get_for_model(self) job = Job(resource_type=resource_type, resource_pk=self.pk, method_name=method_name, natural_id=natural_id, parameters=kwargs) job.set_after_timestamp(after_timestamp) job.save() + job.run(spool=True) return job
mais je me demande si ça ne va pas poser des pb de transaction (genre le job n'est pas encore en DB, et pourtant on l'envoie au spooler)
Updated by Benjamin Dauvergne 12 days ago
Utiliser transaction.on_commit(lambda: job.run(spool=True))
? Si on est dans une transaction ça attendra qu'elle commit, sinon ça lancera le job tout de suite.
PS: on a le même souci avec les logs en base qui disparaissent si jamais on est dans une transaction qui avorte (le cas à ma connaissance n'est pas arrivé, vu qu'on utilise très peu les transactions dans les connecteurs, mais comment en être sûr...).
Updated by Lauréline Guerin 12 days ago
- Status changed from En cours to Solution proposée
- File 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch added
on_commit ajouté (j'ai testé avec et sans, les deux fonctionnent, mais dans un env de prod avec plus de mouvements probablement que sans on_commit on aurait des pb de transaction pas commitées au moment où le spooler prend le job)
j'ai testé en local en mode uwsgi, ça a l'air de tourner.
j'ai laissé la possibilité à la commande cron de traiter les jobs (pour les envs sans uwsgi), tout en supprimant la ligne qui va bien de la crontab.
Updated by Benjamin Dauvergne 11 days ago
Si un job fait raise SkipJob
dans le runjob lancé par le spooler, quand sera-t-il ré-exécuté vu qu'il n'y a plus de cron ? comment est géré set_after_timestamp() dans ce cas ?
runjob ne lock pas la ligne de job, est-ce que le cron et le spooler ne vont pas se marcher sur les pieds ?
À mon avis on devrait conserver le cron (ou utiliser un cronjob dans uwsgi pour cela) pour gérer les rejeux/délais et utiliser select_for_update(skip_locked=True) dans la commande runjob pour éviter que les deux ne se marchent sur les pieds.
Updated by Lauréline Guerin 8 days ago
- File 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch added
cron avec uwsgi
pour info en local je lance ça comme ça:
PASSERELLE_SETTINGS_FILE=/home/lguerin/.config/publik/settings/passerelle/settings.py uwsgi --chdir . --module=passerelle.wsgi:application --env DJANGO_SETTINGS_MODULE=passerelle.settings --master --process 4 --pidfile=/tmp/project-master.pid --http=127.0.0.1:8024 --spooler-python-import=passerelle.utils.spooler --spooler /var/lib/passerelle/spooler/ --cron="-2 -1 -1 -1 -1 passerelle-manage tenant_command cron --all-tenants jobs"
*** Starting uWSGI 2.0.19.1 (64bit) on [Mon Jan 18 10:50:15 2021] *** ... [uwsgi-cron] command "passerelle-manage tenant_command cron --all-tenants jobs" registered as cron task ... Mon Jan 18 10:50:20 2021 - [uwsgi-cron] running "passerelle-manage tenant_command cron --all-tenants jobs" (pid 474438) ... [uwsgi-cron] command "passerelle-manage tenant_command cron --all-tenants jobs" running with pid 474438 exited after 3 second(s)
Updated by Lauréline Guerin 8 days ago
- File 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch 0001-jobs-use-uwsgi-spooler-to-run-jobs-50017.patch added
remplacement de toutes les crontabs
Updated by Thomas Noël 8 days ago
Je ne suis pas sûr à 100% qu'on puisse juste supprimer debian/passerelle.cron.d, car pas sûr que ça supprimera bien les /etc/cron.d/passerelle sur les machines cibles... Sauf si un dev Debian me dit que je manque de confiance, je proposerais de mettre dans ce fichier :
MAILTO=root # all cron are handled by uwsgi, see /etc/passerelle/uwsgi.ini
(et idem pour debian/passerelle.cron.hourly je dirais)
Updated by Frédéric Péters 8 days ago
En virant même le MAILTO, et oui faut faire ainsi (parce que supprimer c'est compliqué, https://wiki.debian.org/DpkgConffileHandling).