Produits Entr'ouvert » Hobo

Par dessus #59094.

1. 0001 : enrichissement de hobo_deploy

Ajout de legacy_urls dans le modèle des services, on met tous les URLS de "l'ancien" service plus un timestamp (voir le hobo.json ci-joint pour voir ce que ça donne), en pratique pour ce patch je n'avais pas besoin de tous les URLS ni du timestamp mais je me dis que ça mange pas de pain et donc pour l'avenir, ça parait raisonnable de tout mettre.

Ensuite l'agent hobo se sert de cette donné pour comprendre qu'on lui demande de changer un tenant existant plutôt que d'en créer un nouveau, pas bien compliqué.

2. 0002 la commande migrate_service : hobo-manage tenant_command migrate_service https://passerelle.dev.publik.love/ https://toto-passerelle.dev.publik.love/ -d hobo.dev.publik.love

Qui s'occupe permet de changer l'URL d'un service et pas seulement son nom de domaine parce que ce n'est pas plus compliqué donc autant avoir cette souplesse qui servira peut-être un jour.
Commande dont sont exclues pour l'instant wcs (parce qu'il a son propre agent qui attend son ticket et son patch), hobo (parce que ça va plutôt passer par un enrichissement de create_hobo_tenant je pense, façon #59094), authentic (parce que je ne mesure pas pour l'instant si ça demande des choses particulières, il faut que je me plonge dedans).

Il y a aussi l'aspect multi-collectivités que je dois tester pour voir si ça nécessite une attention particulière mais bref, un pas après l'autre.

Il y a des trous dans la requête pour les muticollectivités, en l'état un hobo non primaire ne comprends pas qu'il y a eu changement d'URL sur un service, il créé un service supplémentaire.

Enrichie pour les muticollectivité, ie l'agent hobo/hobo (et pas l'agent hobo/common) qui sait interpréter les "legacy_urls" dans les hobo.json.

Ça commence à faire un gros premier patch, pour faciliter les relectures je réduis la portée de ce ticket à "infra de base pour le changement de nom de domaine".

Je met le deuxième patch dans un ticket à part (la commande qui exploite cette infra).

Relecture avec Thomas sur mes genoux.

Arrêter les for/else qui font mal à la tête, plutôt for tout court puis if machin (on se comprend).

Emmanuel Cazenave a écrit :

Arrêter les for/else qui font mal à la tête, plutôt for tout court puis if machin (on se comprend).

Pris en compte.

Thomas Noël a écrit :

On pourrait sans doute éviter cette partie :

[...]

en gérant ça directement au niveau du create_tenant (qui aura reçu le --legacy-hostname et donc aura crée ou mis à jour le local_hobo)

En fait ça ne passe pas dans le create_tenant parce qu'à ce niveau on a plus que le nom de domaine, alors qu'on a besoin de l'URL complet. Du coup un niveau au dessus dans hobo/agent/common/management/commands/hobo_deploy.py :

+        if tenant_created and legacy_domain and self.me['service-id'] == 'hobo':
+            # need to update local hobo
+            with tenant_context(tenant):
+                import hobo.environment.utils
+
+                local_hobo = hobo.environment.utils.get_or_create_local_hobo()
+                if local_hobo.get_base_url_path() != self.me['base_url']:
+                    local_hobo.change_base_url(self.me['base_url'])
+                    local_hobo.save()
+

C'est pas méga élégant ce code spécifique hobo dans agent/common, je préfère la version d'avant (dans la version d'avant le code ajouté dans hobo/agent/hobo/management/commands/hobo_deploy.py:deploy_specifics est assez compréhensible, c'est le reste du code qui y était déjà qui fait mal à la tête).

Thomas Noël a écrit :

Tu fais un retour en arrière ou bien c'est trop pénible ?

Done.

Rebase.

commit f8041c4457ba67aee492cb64f851477cc670a88c
Author: Emmanuel Cazenave <ecazenave@entrouvert.com>
Date:   Wed Dec 1 15:19:45 2021 +0100

    hobo_deploy: handle url change on a service (#58908)