Development #59094
Commande create_tenant : prendre en charge un changement de nom de tenant
0%
Description
Actuellement whatever-manage foo.com crée le tenant foo.com, on voudrait que soit pris en charge un changement de nom de tenant au moyen d'une option : whatever-manage --legacy-hostname olddomain.com foo.com
Une étape sur la route de #58908.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Lié à Support #57729: Migration d'instances de Publik : changement de nom de domaine ajouté
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Fichier 0001-multitenant-add-legacy-hostname-option-to-create_ten.patch 0001-multitenant-add-legacy-hostname-option-to-create_ten.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Paul Marillonnet il y a plus de 2 ans
C’est quoi le gain qui justifie d’avoir ajouté ça à la commande de création de tenant, plutôt que par exemple faire table rase et fournir une commande rename_tenant ?
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
Pas encore visible mais ça minimise fortement les changements dans #58908.
Mis à jour par Paul Marillonnet il y a plus de 2 ans
Ok, je vois des choses dans ce bout de code de la branche wip de #58908 qui indiquent qu’on souhaite supporter la migration directement dans la commande de déploiement. D’où l’inclusion de cette option dans la commande de création de tenant. Ok, je vais relire cette version du patch.
Mis à jour par Paul Marillonnet il y a plus de 2 ans
Il se passe beaucoup de choses ici, je vois que tu testes le cas où le tenant source n’existe pas, mais peux-tu stp tester aussi le cas où le tenant destination existe déjà ?
J’ai l’impression que dans ce cas le code de création échoue silencieusement (Tenant.create_schema retourne une valeur False non traitée dans l’appelant), et que la dernière ligne de la commande va lever une OSError non capturée :
# activate the tenant by creating its directory
os.rename(tenant_dir_tmp, tenant_dir)
(Cf la doc de os.rename : “If dst is a non-empty directory, an OSError is raised.”)
Aussi, peut-être ignorer le paramètre check_if_exists de Tenant.create_schema pour le tenant de destination dans ce scenario de renommage et vérifier systématiquement, puisqu’on le fait déjà pour le tenant source ?
(Je ne comprends pas pourquoi ce paramètre existe dans le code de tenant_schema à la base. Peut-être pour lever explicitement une erreur sur le cursor.execute('CREATE SCHEMA …') dans le cas check_if_exists=False ?)
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Fichier 0001-multitenant-add-legacy-hostname-option-to-create_ten.patch 0001-multitenant-add-legacy-hostname-option-to-create_ten.patch ajouté
Paul Marillonnet a écrit :
Il se passe beaucoup de choses ici, je vois que tu testes le cas où le tenant source n’existe pas, mais peux-tu stp tester aussi le cas où le tenant destination existe déjà ?
Test ajouté, pas eu besoin de toucher au code, ça lève déjà un truc propre :
def handle(self, hostnames, legacy_hostname, **options):
verbosity = int(options.get('verbosity'))
if not hostnames:
raise CommandError("you must give at least one tenant hostname")
if '-' in hostnames: # get additional list of hostnames from stdin
hostnames = list(hostnames)
hostnames.remove('-')
hostnames.extend([x.strip() for x in sys.stdin.readlines()])
if legacy_hostname and len(hostnames) > 1:
raise CommandError("You must specify only hostname when using --legacy-hostname")
for hostname in hostnames:
try:
tenant_base = TenantMiddleware.base()
except AttributeError:
raise CommandError("you must configure TENANT_BASE in your settings")
if not tenant_base:
raise CommandError("you must set a value to TENANT_BASE in your settings")
tenant_dir = os.path.join(tenant_base, hostname)
if os.path.exists(tenant_dir):
> raise CommandError('tenant already exists')
E django.core.management.base.CommandError: tenant already exists
Aussi, peut-être ignorer le paramètre
check_if_existsdeTenant.create_schemapour le tenant de destination dans ce scenario de renommage et vérifier systématiquement
Conjonction de ignorer puis vérifier systématiquement ... j'ai rien compris.
Mis à jour par Paul Marillonnet il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Emmanuel Cazenave a écrit :
Paul Marillonnet a écrit :
Il se passe beaucoup de choses ici, je vois que tu testes le cas où le tenant source n’existe pas, mais peux-tu stp tester aussi le cas où le tenant destination existe déjà ?
Test ajouté, pas eu besoin de toucher au code, ça lève déjà un truc propre :
Parfait, j’avais loupé ça.
Aussi, peut-être ignorer le paramètre
check_if_existsdeTenant.create_schemapour le tenant de destination dans ce scenario de renommage et vérifier systématiquementConjonction de ignorer puis vérifier systématiquement ... j'ai rien compris.
C’est vrai que ce n’est pas très clair et c’est encore moins important, oublions. Ack.
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit ac0079c68a9773df19833949ffd335619a6a6569
Author: Emmanuel Cazenave <ecazenave@entrouvert.com>
Date: Mon Nov 29 17:32:16 2021 +0100
multitenant: add --legacy-hostname option to create_tenant (#59094)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
multitenant: add --legacy-hostname option to create_tenant (#59094)