search

betagouv / mrs

[Startup MRS] Mes remboursements simplifiés
https://www.mrs.beta.gouv.fr/
GNU Affero General Public License v3.0
13 stars 13 forks source link

Envoyer les mails en asynchrone (spool?) #503

Closed fjg closed 6 years ago

fjg commented 6 years ago

L'idée est de pouvoir gérer de la reprise sur erreur en cas d'échec de l'envoi. Est-ce que le spool est une solution ? Sinon en dans le monde rails il existe des frameworks de job (active_job/sidekiq/redis).

jpic commented 6 years ago

Pour rappel on a déjà des spools et des crons en pur uwsgi et on continue dans cette voie d'autant que django-uwsgi-spooler supporte deja crudlfap, et va ajouter de nombreuses feature au fil du temps (start/stop/détails/retries jusqu'à la programmation de crons et tasks spoolée en CRUD tout en supportant graphiquement bien le chaining de tasks et la gestion par hiérarchie).

Je pense que ça nous apportera plus de satisfaction que les autres stacks que j'ai pu pratiquer:

Cette solution ne requiert aucun démon supplémentaire et donc n'a pas de surcoût de maintenance en condition opérationnelle tout étant pilotable par un administrateur CRUDLFA+.

Qu en pensez vous ? D'avance merci pour vos commentaires ;)

Le 7 août 2018 13:45, "fjg" notifications@github.com a écrit :

Assigned #503 https://github.com/betagouv/mrs/issues/503 to @jpic https://github.com/jpic.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/betagouv/mrs/issues/503#event-1775063732, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFxrKusbATHyX1fICNPiZ1PEO5VyryZks5uOX3ZgaJpZM4VyANM .

jpic commented 6 years ago

De plus, le calcul automatique du progrès, l'estimation de temps par tâche, et ce genre de petites bichonneries magiques sont déja prévues mêmes si elles ne sont pas encore dans la PoC. Ça viendra en 1.x par contre.

Le mar. 7 août 2018 à 18:57, Jamesie Pic jpic@yourlabs.org a écrit :

Pour rappel on a déjà des spools et des crons en pur uwsgi et on continue dans cette voie d'autant que django-uwsgi-spooler supporte deja crudlfap, et va ajouter de nombreuses feature au fil du temps (start/stop/détails/retries jusqu'à la programmation de crons et tasks spoolée en CRUD tout en supportant graphiquement bien le chaining de tasks et la gestion par hiérarchie).

Je pense que ça nous apportera plus de satisfaction que les autres stacks que j'ai pu pratiquer:

  • celery+rabbit, marche bien mais cher, et aussi requiert aux tâches d'êtres définies en tant que tâche (typiquement avec décorateur de fonction), rabbit y'a bcp d'options à gérer aussi notamment en terme de sécurité, ensuite la gestion de crise se fait typiquement en ligne de commandes, j'aspire à avoir un CRUD complete et gratuit,
  • django-ztask, c'est pareil en zmq, mais bcp plus léger déjà que celery et rabbit
  • django-rq, pareil avec redis, donc si t'as déjà redis pour ton cache c'est le plus léger,
  • django-q, le petit nouveau et seul que je n'ai pas pratiqué, mais le support du spooler natif uwsgi ne semble pas contribuable car en fait la grosse feature de ce soft est de gérer pour toi ton cluster en utilisant les modèles DB (qui sont très sympas) de tâches, hors, le cluster de workers et le spooler répliqué est déjà dans uwsgi donc toute cette partie est incompatible, j'ai ouvert une issue pour poser la question cela dit
  • django-uwsgi-spooler, la solution YourLabs, part aussi sur des modèles django normaux pour les tâches, mais ne fournit qu'un petit wrapper autours de uwsgi qu'on a déjà pour le cron comme le spoolée (et le cache, je sais, uwsgi est kiffant, c'est le genre de petit soft qui arrive à constamment ajouter des features sans se bloater), et qui va donc vous offrir le plus de features dans votre CRUDLFA+ que vous avez aussi déjà. N'hésitez pas à regarder le README en máster.

Cette solution ne requiert aucun démon supplémentaire et donc n'a pas de surcoût de maintenance en condition opérationnelle tout étant pilotable par un administrateur CRUDLFA+.

Qu en pensez vous ? D'avance merci pour vos commentaires ;)

Le 7 août 2018 13:45, "fjg" notifications@github.com a écrit :

Assigned #503 https://github.com/betagouv/mrs/issues/503 to @jpic https://github.com/jpic.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/betagouv/mrs/issues/503#event-1775063732, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFxrKusbATHyX1fICNPiZ1PEO5VyryZks5uOX3ZgaJpZM4VyANM .

notmoebius commented 6 years ago

Je reformule pour voir si j'ai bien compris: les mécanisme de spools/crons sont en place et il existe des solutions différentes en fonction de choix définis. Tu préconises django-uwsgi-spooler.

Je suis ok pour aller dans ce sens si cela permet de solutionner une "panne"/"bug" de mailjet pour l'envoi de mail.

Est-ce mature pour mettre sur notre production ? Est-ce que cela peut répondre à la problématique soulever lors de notre journée d'hier ?

jpic commented 6 years ago

Django et uwsgi sont déjà en production. Je parle juste d'une poignée de modèles Django qu'on a déjà en production, avec une interface de visualisation autogénérée crudlfa+ qu'on a déjà en production, pour des jobs uwsgi qu'on a déjà en production.

Mais si vous voulez, on peut ramener de la grosse stack pour faire la même chose. On peut ramener un rabbitmq, django-celery, c'est hyper mature, mais est-ce déprécié par django-q ?

Si on met django-q, qui gère ses taches avec des modèles, avec une task queue externe, c'est bien aussi.

Mais dans ce cas pourquoi ne pas mettre django-uwsgi-spooler qui fait la même chose en utilisant la task queue qu'on a déjà ?

The cheapest, fastest, and most reliable components are those that aren’t there. — Gordon Bell

Cela dit, vous pouvez très bien me commander les technologies que vous voulez, le cout ne sera pas le même c'est tout, car j'essaye juste de maitriser la complexité de votre stack, mais si vous souhaitez la complexifier d'avantage c'est votre décision.

One of my most productive days was throwing away 1000 lines of code. — Ken Thompson

fjg commented 6 years ago

OK pour la solution en place actuellement spooler pour l'envoi de tous les mails en asynchrone avec reprise sur erreur (jusqu'à succès). A ce stade, pas besoin d'interface graphique.

jpic commented 6 years ago

Done #528 mais le code c'est un peu spagetti-o, je vais voir si je peux faire qq chose ce week end mais en attendant ca marche pour moi et c'est en route pour staging au moment ou je vous parle.

Merci de valider, pour fermer l'issue:

Bon week ;)

jpic commented 6 years ago

Followup #533 please ;)