Project

General

Profile

Development #59762

check_hobo : gérer un changement de nom de domaine (sur wcs)

Added by Emmanuel Cazenave 5 months ago. Updated 3 months ago.

Status:
Fermé
Priority:
Normal
Target version:
-
Start date:
15 Dec 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Parce qu'arriverait dans le hobo.json un nouvel URL sur wcs et les anciens dans "legacy_urls" (#58908).

Je met "sur wcs" dans la description du ticket parce que je ne sais s'il y a dans check_hobo, une attention particulière à porter sur le fait qu'un autre service que wcs change d'URL.


Files


Related issues

Related to Publik - Support #57729: Migration d'instances de Publik : changement de nom de domaineNouveau11 Oct 2021

Actions

Associated revisions

Revision 42370d2f (diff)
Added by Emmanuel Cazenave 3 months ago

hobo: handle domain change (#59762)

History

#1

Updated by Emmanuel Cazenave 5 months ago

  • Related to Support #57729: Migration d'instances de Publik : changement de nom de domaine added
#2

Updated by Emmanuel Cazenave 5 months ago

  • Status changed from Nouveau to En cours
#3

Updated by Emmanuel Cazenave 5 months ago

Une première version.

J'ai fait quelque choix assez drastiques :

  • passer systématiquement dans configure_sql (alors qu'actuellement on passe dedans uniquement si le répertoire du tenant n'existait pas)
  • dans l'idée que si par exemple le renommage du répertoire réussit mais pas le renommage de la db, le renommage de la DB puisse être re-essayé (en déclenchant un hobo-deploy)
  • du coup je tente de rendre configure_sql idempotent (en me relisant une dernière fois je me rends compte que c'est peut-être loupé, genre pub.initialize_sql() qui sera appelé à chaque hobo_deploy, mais je soumets quand même pour relecture pour arrêter de réfléchir tout seul)
  • au moment de renommer la DB je tue toutes les connexions qui sont faites dessus, parce que j'imagine pas qu'on y arrive (à renommer) dans une situation réelle sans ça (à vrai dire même dans les tests unitaires ça merdait déjà)

J'ai essayé de blinder ça en écrivant des tests qui font vraiment les opérations sur la base de donnée plutôt que mocker les appels psycopg2.

Et tests manuels via #58908 en local, ça marche aussi.

#4

Updated by Frédéric Péters 5 months ago

Je serais pour ne pas toucher du tout au paramétrage de la db, je vois trop les emmerdes.

Par contre il me semble que j'avais regardé et qu'il y a des objets qui peuvent contenir des noms de fichier et inclure une référence à l'ancien répertoire, on peut peut-être se dire que ça passe par les identifier et que ça n'arrive plus et convertir l'existant, plutôt qu'intégrer ça dans cette commande.

#5

Updated by Emmanuel Cazenave 5 months ago

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

Je serais pour ne pas toucher du tout au paramétrage de la db, je vois trop les emmerdes.

C'est dire ne pas renommer la DB ?

#6

Updated by Emmanuel Cazenave 5 months ago

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

Par contre il me semble que j'avais regardé et qu'il y a des objets qui peuvent contenir des noms de fichier et inclure une référence à l'ancien répertoire

Tu aurais une vague piste pour identifier ces objets ?

#7

Updated by Frédéric Péters 5 months ago

À regarder clean_unused_files qui itère partout,

                for part in formdata.iter_evolution_parts():
                    if is_attachment(part):
                        yield part.filename

Voir si c'est un fichier ou chemin relatif.

Plus loin, (et plusieurs fois),

                            if is_upload(field_data):
                                yield field_data.get_fs_filename()

et pour ceux-là, vu get_fs_filename() :

        basedir = os.path.join(get_publisher().app_dir, 'uploads')
        return os.path.join(basedir, self.qfilename)

Et pareil ici vérifier que le qfilename est bien relatif.

Ensuite si jamais il y a des bouts absolus sur un déploiement un peu récent, il y a à adapter le code, mais si on ne trouve rien, en remontant à plus anciens on pourra à coup quasi sûr trouver, et il y aurait donc de toute façon à assurer un run de nettoyage pour ces vieilles instances.

#8

Updated by Frédéric Péters 5 months ago

C'est dire ne pas renommer la DB ?

Oui, ne rien toucher évitera les problèmes.

#9

Updated by Thomas Noël 5 months ago

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

C'est dire ne pas renommer la DB ?

Oui, ne rien toucher évitera les problèmes.

Mmmmhhhh... quels problèmes on imaginerait ?

#10

Updated by Benjamin Dauvergne 5 months ago

Thomas Noël a écrit :

Mmmmhhhh... quels problèmes on imaginerait ?

Un accès externe au schéma ? Le souci que je vois c'est que le mapping passe par un settings actuellement :

    @classmethod
    def hostname2schema(cls, hostname):
        '''Convert hostname to PostgreSQL schema name'''
        if hostname in getattr(settings, 'TENANT_MAPPING', {}):
            return settings.TENANT_MAPPING[hostname]
        schema = hostname.replace('.', '_').replace('-', '_')
        if len(schema) > 63:
            digest = hashlib.md5(smart_bytes(schema)).hexdigest()[:4]
            schema = '%s_%s_%s' % (schema[:29], digest, schema[-28:])
        return schema

si on veut manipuler ça depuis un script ça devrait plutôt être un fichier indépendant, genre /var/lib/brique/<domain>/schema_name.

#11

Updated by Frédéric Péters 5 months ago

(Benjmain ici c'est w.c.s., pas hobo/hostname2schema).

Mmmmhhhh... quels problèmes on imaginerait ?

Sans cette question de renommer la base de données on s'épargne déjà :

du coup je tente de rendre configure_sql idempotent (en me relisant une dernière fois je me rends compte que c'est peut-être loupé, genre pub.initialize_sql() qui sera appelé à chaque hobo_deploy, mais je soumets quand même pour relecture pour arrêter de réfléchir tout seul)
au moment de renommer la DB je tue toutes les connexions qui sont faites dessus, parce que j'imagine pas qu'on y arrive (à renommer) dans une situation réelle sans ça (à vrai dire même dans les tests unitaires ça merdait déjà)

#12

Updated by Frédéric Péters 5 months ago

+                    # rename tenant directory
+                    legacy_tenant_dir = os.path.join(global_tenants_dir, legacy_instance_path)

ne va pas être ok si l'actuel site est dans /var/lib/wcs/ et non /var/lib/wcs/tenants/.

#13

Updated by Emmanuel Cazenave 5 months ago

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

Je serais pour ne pas toucher du tout au paramétrage de la db, je vois trop les emmerdes.

Voilà, je garde quand même la nouvelle "infra" de tests avec les opérations sur la DB réellement exécutées, ça m'a détecté des bugs.

Je m'en étais pas préoccupé dans la précédente version et ça marchait je ne sais comment, mais ici je doit forcer la mise à jour de la configuration 'sp', sinon le SSO marche pas après changement de nom de domaine.

ne va pas être ok si l'actuel site est dans /var/lib/wcs/ et non /var/lib/wcs/tenants/.

Pris en compte, testé.

#14

Updated by Emmanuel Cazenave 5 months ago

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

À regarder clean_unused_files qui itère partout,

Vérification faite sur une instance de recettes, les chemin absolus pullulent.

Pavé dans ma propre marre tant qu'il est encore temps, dans le même ordre d'idées que "Je serais pour ne pas toucher du tout au paramétrage de la db, je vois trop les emmerdes.", je me dis que peut-être ne pas toucher au système de fichiers non plus, juste stocker l'info comme quoi tel tenant se trouve dans tel répertoire qui correspond à son ancien nom de domaine (et du coup ce serait aussi revoir ma copie dans #58908 pour que ça fonctionne pareil coté hobo).

Avis bienvenus.

#15

Updated by Thomas Noël 5 months ago

Emmanuel Cazenave a écrit :

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

À regarder clean_unused_files qui itère partout,

Vérification faite sur une instance de recettes, les chemin absolus pullulent.

Pavé dans ma propre marre tant qu'il est encore temps, dans le même ordre d'idées que "Je serais pour ne pas toucher du tout au paramétrage de la db, je vois trop les emmerdes.", je me dis que peut-être ne pas toucher au système de fichiers non plus, juste stocker l'info comme quoi tel tenant se trouve dans tel répertoire qui correspond à son ancien nom de domaine (et du coup ce serait aussi revoir ma copie dans #58908 pour que ça fonctionne pareil coté hobo).

Avis bienvenus.

A un moment, si ni le répertoire ni la base n'ont le bon nom, je vais trouver ça vraiment moche. Mais si c'est plus simple... Je ne vois quand même pas trop comment on va pouvoir garder l'ancien répertoire. En le remplaçant par un symlink vers le nouveau ?

#16

Updated by Emmanuel Cazenave 5 months ago

Thomas Noël a écrit :

En le remplaçant par un symlink vers le nouveau ?

Non je me disais vraiment pas toucher au système de fichier, juste poser l'info comme quoi le tenant new-xxx, son répertoire c'est xxx (j'imagine que c'est l'agent hobo, ici check_hobos.py, qui pose cette info dans un fichier genre /var/lib/wcs/tenant-map.whatever), et ensuite il y a aurait à exploiter cette info dans QommonPublisher.set_tenant_by_hostname.

#17

Updated by Frédéric Péters 5 months ago

Vérification faite sur une instance de recettes, les chemin absolus pullulent.

Ce n'est quand même pas bien correct, si tu as encore les infos sous la main, ça m'intéresse d'avoir ça, identifier les origines pour les corriger. ("on peut peut-être se dire que ça passe par les identifier et que ça n'arrive plus et convertir l'existant").

#18

Updated by Emmanuel Cazenave 5 months ago

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

Ce n'est quand même pas bien correct, si tu as encore les infos sous la main, ça m'intéresse d'avoir ça, identifier les origines pour les corriger.

Sur wcs.node1.test.saas.entrouvert.org:/home/ecazenave/wcs_showfilenames.py lancé sur demarches-metz.test.entrouvert.org via runscript.

#19

Updated by Emmanuel Cazenave 5 months ago

Sur les chemins de fichiers ça semble en fait plutôt favorable #60302, je remballe mes idées de ne pas renommer le répertoire du tenant, relecture bienvenue du coup.

#20

Updated by Thomas Noël 4 months ago

Relu ensemble, tout me semble ok.

Frédéric tu jettes un oeil ou tu as confiance en Manu et moi ? ;)

(il faudra avoir aussi #60380 pour ne plus être sensible au nom du répertoire /var/lib/wcs/... mais c'est annexe)

#21

Updated by Thomas Noël 4 months ago

  • Status changed from Solution proposée to Solution validée
#22

Updated by Thomas Noël 4 months ago

Note : il faudra aussi enregistrer tous les legacy_urls dans le site-options, genre sous cette forme :

[legacy-urls]
ancien.site = nouveau.site
ancien2.site = nouveau.site
vieux.truc = nouveau.truc

afin qu'on puisse modifier les URL des requests vers des anciens sites à la volée.

Ca peut être géré dans un autre ticket «conserver les anciennes URLs après une modification des URL d'un service par check_hobo». L'infra de base ici est bien.

#23

Updated by Frédéric Péters 4 months ago

(il faudra avoir aussi #60380 pour ne plus être sensible au nom du répertoire /var/lib/wcs/... mais c'est annexe)

Annexe modulo qu'il ne faudra surtout pas renommer un tenant avant de l'avoir.

(côté relecture je fais confiance, je ne vais pas la doubler)

#24

Updated by Emmanuel Cazenave 3 months ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 42370d2fb000370d3605d9b58a72a9b8c599f9b1
Author: Emmanuel Cazenave <ecazenave@entrouvert.com>
Date:   Wed Dec 22 15:00:56 2021 +0100

    hobo: handle domain change (#59762)
#25

Updated by Transition automatique 3 months ago

  • Status changed from Résolu (à déployer) to Solution déployée
#26

Updated by Transition automatique about 1 month ago

Automatic expiration

Also available in: Atom PDF