Produits Entr'ouvert » w.c.s.

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.

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 ?

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 ?

À 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.

C'est dire ne pas renommer la DB ?

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

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 ?

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.

(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à)

+                    # 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/.

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.

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 ?

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.

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").

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.

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.

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)

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.

(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)

Automatic expiration