Produits Entr'ouvert » Hobo

Ok mais 120 secondes ça va en pratique continuer à péter, ce qu'il faut à mon sens c'est passer le traitement en asynchrone (i.e. on reçoit le message, on le met de côté, on répond ok à authentic, on traite le message); on a des spooler uwsgi presque partout désormais pour gérer ça.

Frédéric Péters a écrit :

Ok mais 120 secondes ça va en pratique continuer à péter, ce qu'il faut à mon sens c'est passer le traitement en asynchrone (i.e. on reçoit le message, on le met de côté, on répond ok à authentic, on traite le message); on a des spooler uwsgi presque partout désormais pour gérer ça.

Sur cette affaire : ne risque-t-on pas de se manger des conflits ? Il me semblait (mais je peux me tromper) que le passage par RabbitMQ assurait que les messages étaient traités un par un, et dans l'ordre d'arrivée. Avec un système asynchrone on va perdre ça, parce que les spoolers sont multiples, et que je suis pas sûr qu'ils gèrent un ordre. Et donc un message n°1 qui ajoute un rôle pourrait être joué après le n°2 qui le supprime, et au final le rôle sera toujours là.

Mais peut-être que je me trompe par rapport à RabbitMQ et dans ce cas, oui, l'asynchrone ça serait chouette.

A vrai dire j'avais pensé au spooler uwsgi je ne m'y suis pas lancé parce qu'incapable de répondre à la question "qu'est ce qu'on gagne par rapport à rabbitmq en passant par uwsgi ?".

C'est une vraie question que je pose, pas une fin de non recevoir sur l'approche.

Emmanuel Cazenave a écrit :

A vrai dire j'avais pensé au spooler uwsgi je ne m'y suis pas lancé parce qu'incapable de répondre à la question "qu'est ce qu'on gagne par rapport à rabbitmq en passant par uwsgi ?".
C'est une vraie question que je pose, pas une fin de non recevoir sur l'approche.

Je dirais, dans un avenir plus ou moins proche, ne plus utiliser RabbitMQ ? C'est encore illusoire mais bon, je sais que t'aime aussi les compètes d'endurance.

En attendant, passer par HTTP simplifie quand même beaucoup le débogue voir la supervision (mesure des temps de réponse). Dans authentic on pourra recevoir le nom du job créé et aller le "voir" tourner sur le logiciel cible.

Note que pour moi on ne ferait pas systématiquement de l'async. Imaginer que l'async ne se déclenche que si le volume reçu dans le notify est jugé important, avec un settings.HOBO_AGENT_NOTIFY_ASYNC_THRESHOLD=<nombre d'actions à partir duquel on répond en async>.

"qu'est ce qu'on gagne par rapport à rabbitmq en passant par uwsgi ?".

ne plus utiliser RabbitMQ

Oui c'est totalement l'objectif; pour reprendre des points fournis dans #43245 qui a introduit le provisionning HTTP : c'est trop compliqué de débugguer les problèmes RabbitMQ, on n'a aucun outil d'analyse; comme on tourne rabbitmq avec un unique worker ça fait un goulot d'étranglement global, partagé par tous les tenants. Aussi, ça assure (dans le cas commun d'ajout d'un utilisateur, ou d'un rôle) un provisionning synchrone, ce qui est d'une grande aide dans les workflows qui font ça.

_~~

Sur cette affaire : ne risque-t-on pas de se manger des conflits ?

Je ne suis pas si sûr de ce que rabbitmq assurait réellement. (et vu le nombre de fois où il a fallu retirer/remettre un rôle pour voir le provisionning se faire, parce que message expiré/perdu, l'éventuel conflit devait passer inaperçu).

Si on en arrive aux conflits, je ne me suis pas remis de vrais messages de provisionning sous les yeux mais je pense qu'on arriverait à les faire évoluer pour inclure des timestamps pour éviter ça.

Imaginer que l'async ne se déclenche que si le volume reçu dans le notify est jugé important, avec un settings.HOBO_AGENT_NOTIFY_ASYNC_THRESHOLD=<nombre d'actions à partir duquel on répond en async>.

Volume important ou message précédemment passé en asynchrone et pas encore traité.

Emmanuel Cazenave a écrit :

C'est une vraie question que je pose, pas une fin de non recevoir sur l'approche.

Ça n'a pas de rapport; mais oui l'implémentation d'une queue est un peu lourde avec RabbitMQ et trop simple dans certains cas dans uwsgi mais RabbitMQ n'est pas un gestionnaire de jobs.

Ce que je pense c'est qu'on doit passer d'un modèle push à un modèle pull, et là pas de souci pour jeter ça dans un spooler. Mais il faudrait pouvoir faire des mise à jour incrémentales et pour ça il nous manque un timestamp sur le modèle "through" de Role.members pour la création et un soft delete. Une fois qu'on a ça on peut avoir un web-service qui nous sert les rôles récents ainsi que les changements d'appartenance depuis une date donnée et authentic n'aura plus qu'à envoyer un message en HTTP "un truc à changer sur les rôles, mets toi à jour" et coté appli on peut faire des mises à jour régulière au cas où un message se soit perdu à un moment.

À noter qu'on pourra faire pareil pour les utilisateurs (il manque sur les utilisateurs un changement de timestamp quand on l'ajoute/retire d'un rôle aussi, ça nous le donnera).

PS: en donc oui celery et rabbitmq sont bien trop compliqués pour nos usages.

Au passage j’ai l’impression que dans 0002, quitte à optimiser on doit pouvoir taper au moins une compréhension de dictionnaire, genre à la place de :

            for role in Role.objects.filter(uuid__in=target_uuids):
                roles_by_uuid[role.uuid] = role