Project

General

Profile

Development #50017

utiliser le spooler uwsgi pour l'exécution des jobs

Added by Frédéric Péters 16 days ago. Updated 8 days ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
10 Jan 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

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

#1

Updated by Lauréline Guerin 14 days ago

  • Assignee set to Lauréline Guerin
#2

Updated by Lauréline Guerin 12 days ago

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

#3

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

#4

Updated by Lauréline Guerin 12 days ago

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.

#5

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.

#7

Updated by Lauréline Guerin 8 days ago

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

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)

#10

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

Also available in: Atom PDF