Produits Entr'ouvert » Hobo

Pour que les changements de profile usager (https://hobo.dev.publik.love/profile/) arrive dans authentic, il faudrait lui ajouter un middleware de provisionning pour gérer ça

Pourquoi on utilise pas simplement postgresql pour communiquer ? On a déjà un moyen de transport commun via postgres, les tenants hobo pose les fichiers hobo.json dans une table avec un timestamp et les hobo-agent viennent les lire, on peut utiliser LISTEN/NOTIFY pour le signal¹. Et comme ça on ne change rien à part l'implémentation de hobo-agent, on dégage celery et rabbitmq et on est pas soumis aux aléas de requêtes HTTP.

¹ https://www.psycopg.org/docs/advanced.html#async-notify

Ok mais l'idée c'est que ça devienne synchrone et ne fasse pas réagir toutes les instances. Pas de ne rien changer.

De ce que je comprends on resterai dans un modèle ou toutes les instances réagissent à tous les événements mais ne font rien 99.9% du temps. En http, on cible précisément les instances qui doivent faire quelque chose. Et c'est assez rapide.

En prime, on aurait aussi des aléas avec une connection postgres, non ? Qu'est ce qui ce passe si le serveur reboot, ou qu'on sature le nombre de connexions ? Certes c'est moins courant qu'un soucis http mais sur le papier on s'expose plus ou moins aux même soucis: rater des événements. J'imagine que c'est pour cela qu'il y a un cron de provisionning.

Pour finir, le http ne concerne que le provisionning (certes c'est le plus critique pour nos clients). Pour ce qui est du déploiement/renommage d'instance on se contente de lancer des sous process dans un pool de thread sans intermédiaire. Pour ce cas c'est clairement mieux pour nous de ne pas avoir d'intermédiaire.

Ceci étant dit je ne suis pas fermé à passer par une queue postgres pour le provisionning. Il faudrait peut-être lancer la discussion un lundi si tu es convaincu.

Gael Pasgrimaud a écrit :

Ok mais l'idée c'est que ça devienne synchrone et ne fasse pas réagir toutes les instances. Pas de ne rien changer.

De mon coté c'est pas du tout mon idée, l'idée c'est d'enlever des éléments de la stack pour la simplifier le coté synchrone me semble pas utile, à la rigueur avoir un retour oui (savoir si la mise à jour a eu lieu, avec une queue sur postgres ce serait assez facile à faire).

De ce que je comprends on resterai dans un modèle ou toutes les instances réagissent à tous les événements mais ne font rien 99.9% du temps. En http, on cible précisément les instances qui doivent faire quelque chose. Et c'est assez rapide.

Ok mais c'est ce plan là qui n'est pas décrit alors, on ne passe plus par un simple push(get_hobo_json()) on a quelque chose de plus fin qui est capable de dire quelle instance est intéressée par la mise à jour ?

En prime, on aurait aussi des aléas avec une connection postgres, non ? Qu'est ce qui ce passe si le serveur reboot, ou qu'on sature le nombre de connexions ? Certes c'est moins courant qu'un soucis http mais sur le papier on s'expose plus ou moins aux même soucis: rater des événements. J'imagine que c'est pour cela qu'il y a un cron de provisionning.

Sans postgres on ne peut pas accéder à hobo et donc difficilement changer la configuration, c'est un non problème, postgres est toujours là, c'est une certitude.

Pour finir, le http ne concerne que le provisionning (certes c'est le plus critique pour nos clients). Pour ce qui est du déploiement/renommage d'instance on se contente de lancer des sous process dans un pool de thread sans intermédiaire. Pour ce cas c'est clairement mieux pour nous de ne pas avoir d'intermédiaire.

Le provisionning est déjà en HTTP ou j'ai raté un truc, on peut juste désactiver le coté celery dès maintenant.

Ceci étant dit je ne suis pas fermé à passer par une queue postgres pour le provisionning. Il faudrait peut-être lancer la discussion un lundi si tu es convaincu.

En fait pour moi provisionning + rabbitmq = déploiement, je pense que je n'ai peut-être pas tout compris.

Benjamin Dauvergne a écrit :

Gael Pasgrimaud a écrit :

Ok mais l'idée c'est que ça devienne synchrone et ne fasse pas réagir toutes les instances. Pas de ne rien changer.

De mon coté c'est pas du tout mon idée, l'idée c'est d'enlever des éléments de la stack pour la simplifier le coté synchrone me semble pas utile, à la rigueur avoir un retour oui (savoir si la mise à jour a eu lieu, avec une queue sur postgres ce serait assez facile à faire).

C'est ce qui avait été dit en eocamp. Possible qu'il n'y ai pas eu de CR clair.

De ce que je comprends on resterai dans un modèle ou toutes les instances réagissent à tous les événements mais ne font rien 99.9% du temps. En http, on cible précisément les instances qui doivent faire quelque chose. Et c'est assez rapide.

Ok mais c'est ce plan là qui n'est pas décrit alors, on ne passe plus par un simple push(get_hobo_json()) on a quelque chose de plus fin qui est capable de dire quelle instance est intéressée par la mise à jour ?

En prime, on aurait aussi des aléas avec une connection postgres, non ? Qu'est ce qui ce passe si le serveur reboot, ou qu'on sature le nombre de connexions ? Certes c'est moins courant qu'un soucis http mais sur le papier on s'expose plus ou moins aux même soucis: rater des événements. J'imagine que c'est pour cela qu'il y a un cron de provisionning.

Sans postgres on ne peut pas accéder à hobo et donc difficilement changer la configuration, c'est un non problème, postgres est toujours là, c'est une certitude.

C'est vrai, sauf quand tu lance quelques chose et que ça coupe en cours. La, tu sais absolument pas ce qui a été fait et ce qui reste à faire. Tant que c'est re-jouable, ça passe

Pour finir, le http ne concerne que le provisionning (certes c'est le plus critique pour nos clients). Pour ce qui est du déploiement/renommage d'instance on se contente de lancer des sous process dans un pool de thread sans intermédiaire. Pour ce cas c'est clairement mieux pour nous de ne pas avoir d'intermédiaire.

Le provisionning est déjà en HTTP ou j'ai raté un truc, on peut juste désactiver le coté celery dès maintenant.

Pas entièrement. Les profiles/variables hobo ne remonte pas dans authentic en http, ou alors c'est moi qui rate un truc. Mais surtout je ne suis pas certain qu'on parles de la même chose.

Ceci étant dit je ne suis pas fermé à passer par une queue postgres pour le provisionning. Il faudrait peut-être lancer la discussion un lundi si tu es convaincu.

En fait pour moi provisionning + rabbitmq = déploiement, je pense que je n'ai peut-être pas tout compris.

Pour moi le déploiement c'est la création d'une instance. Le provisionning (et ça n'est pas vraiment le bon terme non plus), c'est la synchro une fois l'instance déployée (users/roles depuis authentic, profile/variables depuis hobo)
C'est ma vision dans l'absolu. Mais dans publik j'ai l'impression que à l'exception de la synchro uesr/roles authentic tout est fait tout le temps. Ca lance des hobo_deploy. Il n'y a pas ou trop peu de logs.

En l'état, c'est difficile pour moi de savoir ce qui se passe et toutes les possibilités offertes (avec les histoires de primary/secondary, etc.). Je pensais avoir quelques chose qui fonctionne mais en fait non. (impossible de m'authentifier à hobo via authentic)

Ma dernière réflexion à moi même m'amène à me dire que tout ce qui est création d'instance devrait être géré par ansible (parce que je ne déteste pas trop ansible). Que ça permettrai de savoir ce qui se passe plus facilement. C'est synchrone. Une tache, un retour. Et que ça permettrai aussi de déployer de la même manière sur un ou X serveurs. Mais vu que tout n'est pas encore clair dans ma tête et que ce n'est pas l'objet du chantier il vaut mieux ignorer ça.

Gael Pasgrimaud a écrit :

En l'état, c'est difficile pour moi de savoir ce qui se passe et toutes les possibilités offertes (avec les histoires de primary/secondary, etc.). Je pensais avoir quelques chose qui fonctionne mais en fait non. (impossible de m'authentifier à hobo via authentic)

Et en fait je réalise qu'on peut ajouter un service depuis l'UI hobo. Ce que j'avais inconsciemment complètement omis aussi. Et qui explique pourquoi quand quelques choses change dans hobo "tout" est rejoué partout.

Maintenant qu'il y a des logs et surtout que je me suis poussé à créer des tenants secondaire via #106774 j'y vois un peu plus clair.

Dans #103431 il y a un patch minimaliste (très peu de code qui ne casse pas les tests) qui permet de se passer de celery pour le déploiement en local. Je suis surpris que ça fonctionne mais le fait est que ça fonctionne.

Je ne suis pas certain qu'on ai intérêt à faire du séquentiel pure et dur à la création des tenants. Les déploiements de combo/authentic sont lent (à nouveau, il faudrait squash les migrations). On a tout intérêt à tout lancer en même temps.

Il y aussi le fait que l'une des commandes lancées: hobo/agent/hobo/management/commands/hobo_deploy.py, lance aussi un "déploiement" via notify_agents. J'imagine principalement pour propager les variables et profile. Mais aussi peut-être pour tout ce qui est déclaration de service. Même si à priori ici ça ne va pas en créer/supprimer. Tous les tenants (primaire et secondaire) partagent le même hobo.json. Je n'ai encore pas encore une assez bonne vision pour trancher ce point. Et aussi, je ne sais pas si on aurait intérêt à faire du provisionning http à ce niveau. Je serai plus pour conserver le principe de hobo_notify qui réagit aux même payload que https://__provisionning__/

A cause de cette commande, je penses qu'il sera très compliqué de créer des Publik avec interco "à la main" pour le cas ou tous les services ne serait pas sur la même machine.

Pour une instance simple, il devrait être possible d'afficher les commandes à lancer au lieu de les lancer vraiment. (et peut-être que je suis pessimiste et que ça marcherai pour de l'interco aussi)

Bref, ça avance. Pour moi la prochaine étape est de gérer le provisionning des variables/profiles en http (et donc idéalement aussi compatible avec la commande hobo_notify)

Petit point. Ca avance (lentement).

Il y a maintenant de quoi propager les variables (en fait tout le hobo.json) dans les briques. Sauf wcs qui a un endpoint de provisionning spécifique

Il y a des tests unitaire qui passent

J'ai fait pas mal de test manuel (sans hobo secondaire pour l'instant). Ca semble pas trop mal fonctionner

A ce stade il manque encore au moins deux/trois choses:

- qu'on puisse lancer le cron hobo soit en http soit en subprocess. en http ça sera utile si tout n'est pas sur une même machine (en fait ça ne marchera pas sans) et via un subprocess c'est plus simple à tracer (on peut aussi dire que ça doit toujours passer en http)

- que le provisionning des hobo.json se lance dans un afterjob. ça pourrait prendre trop de temps

- qu'on puisse propager le hobo.json dans wcs depuis le endpoint /__provision__/

Pour l'instant je laisse ce dernier point de coté. Quand il ne restera que ça, ça sera trivial.

Aussi, je penses qu'il est indispensable d'ajouter un "--dry-run" à la commande cook. Ce qui permetra de tracer les commandes à lancer manuellement pour initier une instance dans une infra multi-machine. Et ça ça ne me semble vraiment pas gagné dans le cas ou il y a des hobo secondaire

Premier build devinst qui passe sans rabbitmq via #109667

Par contre j'ai du casser le build hobo dans #62020 pour en arriver là (je n'explique pas que ça casse à cause du dernier commit)

A ce stade je suis obligé de ne travailler qu'en local. Vu que sur jenkins on cache les image utilisées par functest on ne peut que dificilement tester des changements majeurs dans le playbook devinst (ici ne pas installer rabbitmq)

Mais en local, le tout fonctionne pas trop mal. Le test fonctionnel qui test la propagation des variables échoue:

tests/test_hobo.py:49: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

condition = <function test_variable_propagation.<locals>.condition at 0x7f0cdebd3600>

    def check_hobo_jsons_data(condition):
        start = time.time()
        invalid = True
        while invalid:
            invalid = []
            for tenant, data in hobo_jsons():
                if condition(data):
                    invalid.append(tenant)
            if not invalid:
                break
            if time.time() - start > 60:
                # should't take that long
                break
            time.sleep(1)
>       assert not invalid, f'condition not valid for tenants: {invalid}'
E       AssertionError: condition not valid for tenants: ['hobo', 'wcs']
E       assert not ['hobo', 'wcs']

tests/test_hobo.py:30: AssertionError

Le hobo.json n'arrive pas dans wcs. C'est normal. Il manque une PR pour ça.

Par contre il n'arrive pas dans hobo non plus. Mais la je dirai que c'est aussi normal et que c'est l'état actuel qui est surprenant. Hobo ne devrait jamais utiliser ce fichier et donc il ne devrait même pas être présent.

C'est maintenant presque tout bon. Y compris avec les paquets debian.

Il subsiste un truc étrange. Quand on utilise les paquets debian il faut restart le service hobo après avoir renommé un hobo. Sinon il ne réponds pas. Je ne comprends pas trop pourquoi

TLDR: il reste des taches mais en vrai ça fonctionne. en local les tests fonctionnels passent avec une image debinst en trixie (sans rabbitmq, donc). cest tests lance un déploiement et 4 renommage de service: combo/hobo en primaire/secondaire

Ce n'est pas évident d'avancer la dessus. Il faut se (re)mettre dans ce gros morceau en assurant le support. Mais j'ai enfin réussis (merci la nuit).

Il n'y a pas d'avancées notable par rapport au dernier point. Ca fonctionnait déjà. J'ai passé beaucoup de temps à essayé de comprendre pourquoi le restart de service est nécessaire quand on renomme un service mais je ne comprends pas. Ca ressemble à un soucis de cache de tenant ou autre. On voit des traces qui concerne un tenant renommé (comme combo.dev.publik.love) mais quand on restart le service tout est immédiatement ok. Super louche et pas facilement debugable.

Je ne penses pas que ce soit bloquant. On ne renomme pas des tenants tous les jours. Si dans la procédure on a "restart le service", ça me semble acceptable. (même si à terme il faudrait vraiment fixer ça)

Ce n'est pas évident de prouver que tout cela fonctionne via une CI. Et il va donc rester des étapes nécessaire:

- fixer les tests unitaires. je fais des tests en conditions réelles dans une vm et du coup j'ai mis ça de coté sur la fin

- faire en sorte d'avoir une image debinst sur jenkins pour pouvoir lancer les tests fonctionnels dessus. c'est le seul moyen de prouver que le packaging debian est ok. dans un premier temps on pourrait se contenter d'uploader une (ou des) image construite en locale (car on ne veut pas déployer un paquet debian de hobo avec une branche)

Gael Pasgrimaud a écrit (#note-26):

Il n'y a pas d'avancées notable par rapport au dernier point. Ca fonctionnait déjà. J'ai passé beaucoup de temps à essayé de comprendre pourquoi le restart de service est nécessaire quand on renomme un service mais je ne comprends pas. Ca ressemble à un soucis de cache de tenant ou autre. On voit des traces qui concerne un tenant renommé (comme combo.dev.publik.love) mais quand on restart le service tout est immédiatement ok. Super louche et pas facilement debugable.

Tu pourrais pointer un ticket avec une telle trace ou s'il n'y en a pas en copier une ici ?

Benjamin Dauvergne a écrit (#note-29):

Tu pourrais pointer un ticket avec une telle trace ou s'il n'y en a pas en copier une ici ?

On tombe la dessus quand on lance check_operationnal (qui check maintenant les urls de metadata) mais c'est vrai avec n'importe quelle url:

déc. 16 08:57:31 testvm uwsgi/hobo[1308]: Traceback (most recent call last):
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/django/core/handlers/wsgi.py", line 121, in __call__
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     set_script_prefix(get_script_name(environ))
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:                       ~~~~~~~~~~~~~~~^^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/django/core/handlers/wsgi.py", line 162, in get_script_name
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     if settings.FORCE_SCRIPT_NAME is not None:
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:        ^^^^^^^^^^^^^^^^^^^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/apps.py", line 30, in <lambda>
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     conf.LazySettings.__getattr__ = lambda self, name: getattr(self._wrapped, name)
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:                                                        ~~~~~~~^^^^^^^^^^^^^^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/settings.py", line 102, in __getattr__
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     return getattr(self.get_wrapped(), name)
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:                    ~~~~~~~~~~~~~~~~^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/settings.py", line 97, in get_wrapped
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     return self.get_tenant_settings(tenant)
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:            ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/settings.py", line 70, in get_tenant_settings
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     new_digest = self.get_digest(tenant)
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/settings.py", line 54, in get_digest
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     return hash(tuple(loader.get_new_time(tenant) for loader in self.loaders))
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:                 ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/settings.py", line 54, in <genexpr>
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     return hash(tuple(loader.get_new_time(tenant) for loader in self.loaders))
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:                       ~~~~~~~~~~~~~~~~~~~^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:   File "/usr/lib/python3/dist-packages/hobo/multitenant/settings_loaders.py", line 434, in get_new_time
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:     return os.stat(tenant_dir).st_mtime
déc. 16 08:57:31 testvm uwsgi/hobo[1308]:            ~~~~~~~^^^^^^^^^^^^
déc. 16 08:57:31 testvm uwsgi/hobo[1308]: FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/hobo/tenants/secondary-hobo.dev.publik.love'
déc. 16 08:57:31 testvm uwsgi/hobo[1308]: [pid: 1308|app: 0|req: 257/943] 0.0.0.0 () {38 vars in 543 bytes} [Tue Dec 16 09:57:31 2025] GET /accounts/mellon/metadata/ => generated 0 bytes in 5 msecs (HTTP/1.0 500) 0 headers in 0 bytes (0 switches on core 0)

Et en fait ça fini par fonctionner. Mais ça prends beaucoup trop de temps alors que ça devrait être "immédiat". Pour moi ça confirme que c'est un soucis de cache quelque part.

Je ne vois pas de code qui serait lancé en tache de fond qui modifierai le comportement.