Produits Entr'ouvert » Hobo

Lors du déploiement.

Traceback (most recent call last):
  File "/usr/lib/combo/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 295, in run_from_argv
    stderr.write('%s: %s' % (e.__class__.__name__, e))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 79: ordinal not in range(128)
[2016-02-06 10:23:27,338: INFO/MainProcess] Task hobo-deploy[33a36fcc-b1ab-49bd-aab9-acf88e24d7a6] succeeded in 25.2780017816s: None

En changeant pour mettre des %r :

'CommandError': CommandError("tenant creation failed (ERREUR:  une instruction insert ou update sur la table \xc2\xab auth_permission \xc2\xbb viole la contrainte de cl\xc3\xa9\n\xc3\xa9trang\xc3\xa8re \xc2\xab auth_content_type_id_508cf46651277a81_fk_django_content_type_id \xc2\xbb\nDETAIL:  La cl\xc3\xa9 (content_type_id)=(16) n'est pas pr\xc3\xa9sente dans la table \xc2\xab django_content_type \xc2\xbb.\n)",)

Et le schéma est créé donc lors de l'hobo_deploy suivant ça semble passer et en fait, non, c'est tout cassé.

À exécuter le create_tenant en mode verbose :

...
  Applying wcs.0009_remove_wcscategorycell_link_page... OK
  Applying wcs.0010_auto_20151029_1535... OK
  Applying wcs.0011_auto_20151215_1121... OK
'CommandError': CommandError("tenant creation failed (ERREUR:  une instruction insert ou update sur la table \xc2\xab auth_permission \xc2\xbb viole la contrainte de cl\xc3\xa9\n\xc3\xa9trang\xc3\xa8re \xc2\xab auth_content_type_id_508cf46651277a81_fk_django_content_type_id \xc2\xbb\nDETAIL:  La cl\xc3\xa9 (content_type_id)=(16) n'est pas pr\xc3\xa9sente dans la table \xc2\xab django_content_type \xc2\xbb.\n)",)

Ça ressemble à un souci lié au cache des objets ContentType; le code multitenant contient des appels à ContentType.objects.clear_cache() quand on change de schéma mais là il doit en manquer un au bon endroit, je ne trouve pas la plateforme ou reproduire le bug, mais ajouter un print dans clear_cache et voir quand il est appelé pourrait être utile.

Néanmoins avec un migrate_schemas ciblé avec l'option -d ça ne devrait pas arriver puisque qu'on ne chargerait pas les ContentType d'un autre tenant avant, idem pour la création du schéma dans reate_tenant il me semble qu'on ne devrait pas avoir le temps de charger le cache des ContentType dans le schéma public, mais pareil il faudrait vérifier les appels à ContentType._add_to_cache (dans django/contrib/contentypes/models.py) et voir le tenant en cours à chaque appel (du django.db.connection.schema ou tenant).

Pas évident mais j'ai trouvé la source du problème. Il y a dans combo.data.apps ce code:

    def ready(self):
        from .library import library
        library.ready()

qui appelle donc ce code ci:

    def ready(self):
        # initialize the dictionary
        self.classes_by_content_str = {}
        for klass in self.classes:
            try:
                content_type = ContentType.objects.get_for_model(klass)
            except RuntimeError:
                # this is for RuntimeError: Error creating new content types.
                # Please make sure contenttypes is migrated before trying to
                # migrate apps individually.
                #
                # If that happens we switch to lazy initialization.
                self.classes_by_content_str = None
                break
            content_type_str_v = '%s_%s' % (content_type.app_label, content_type.model)
            self.classes_by_content_str[content_type_str_v] = klass

or au moment du ready() on est pas dans le contexte du tenant mais dans le contexte "public". L'utilisation du modèle ContentType force l'initialisation du cache de ContentType (ainsi que la création des modèles qui n'existeraient pas normalement). Ensuite lors du passage dans le premier tenant, le signal post_migrate est appelé pour l'application momo qui est la première dans la liste, cela appelle le handler de django.contrib.auth pour la création des permissions, qui recherche le ContentType pour momoiconcell qui n'a pas le même id dans la base public que dans le tenant de portail-agent.alfortville.fr et boum; il faut en plus que l'id trouvé dans la table du schéma public ne correspondent à aucun id existant, sinon l'erreur devient invisible (mais les permissions sont foirées). Ce qui est bizarre c'est que la table django_content_type ne devrait même pas exister, mais je pense que la base a été initialisée à une époque où on avait encore django.contrib.contenttypes listé dans SHARED_APPS.

Je pense qu'il faudrait remplacer ce code de combo par une utilisation de klass._meta.app_label, klass._meta.model_name car en plus il est contre-indiqué d'accéder aux modèles dans les méthodes ready()[1] et ici ContentType ne me semble pas servir à grand chose. Fred est-ce que tu te souviens pourquoi tu as utilisé ContentType plutôt que l'objet Meta des modèles ?

[1]: https://docs.djangoproject.com/en/1.9/ref/applications/#django.apps.AppConfig.ready

Le problème est d'ailleurs présent aussi sur portail-agents.vincennes.fr mais il n'est pas gênant:

 154 | Can add Meta for mobile            |              16 | add_momoiconcell
 155 | Can change Meta for mobile         |              16 | change_momoiconcell
 156 | Can delete Meta for mobile         |              16 | delete_momoiconcell
 160 | Can add Meta for mobile            |              38 | add_momoiconcell
 161 | Can change Meta for mobile         |              38 | change_momoiconcell
 162 | Can delete Meta for mobile         |              38 | delete_momoiconcell

idem sur fontenay:

 106 | Can add Meta for mobile            |              16 | add_momoiconcell
 107 | Can change Meta for mobile         |              16 | change_momoiconcell
 108 | Can delete Meta for mobile         |              16 | delete_momoiconcell

dès qu'on a le content_type_id == 16.

go.