Envoyer les mails en asynchrone (spool?) #503
Comments
|
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 <#503> to @jpic
<https://github.com/jpic>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#503 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAFxrKusbATHyX1fICNPiZ1PEO5VyryZks5uOX3ZgaJpZM4VyANM>
.
|
|
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" ***@***.***> a écrit :
Assigned #503 <#503> to @jpic
<https://github.com/jpic>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#503 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFxrKusbATHyX1fICNPiZ1PEO5VyryZks5uOX3ZgaJpZM4VyANM>
.
|
|
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 ? |
|
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à ?
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.
|
|
OK pour la solution en place actuellement spooler pour l'envoi de tous les mails en asynchrone avec reprise sur erreur (jusqu'à succès). |
|
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 ;) |
|
Followup #533 please ;) |
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).
The text was updated successfully, but these errors were encountered: