h1. HowDoWeDoDjangoTenants Individuellement les projets n'ont pas à se soucier de multitenant, c'est totalement pris en charge par de la configuration. Voir http://git.entrouvert.org/hobo.git/tree/debian/debian_config_common.py?h=master (à partir de @# multitenant adaptations@, ligne 206) Exemple de fichier @/usr/lib//debian_config.py@ appelé à la fin du @settings.py@ du projet :
# /usr/lib//debian_config.py
# appelé en execfile() en toute fin des settings.py de 

PROJECT_NAME = 'foobar'

# si nécessaire:
#INSTALLED_APPS += ('mellon',)   # SAML2 authentication

execfile('/usr/lib/hobo/django_config_common.py')   # cf http://git.entrouvert.org/hobo.git/tree/debian/debian_config_common.py?h=debian

# en cas de besoin supplémentaire au niveau de la gestion des settings.py
# par tenant pour . Par exemple pour Authentic:
TENANT_SETTINGS_MIDDLEWARE_LOADERS = +(
        'hobo.multitenant.settings_loaders.Authentic',
        # 'hobo.multitenant.settings_loaders.SettingsPy',
)

execfile('/etc/%s/settings.py' % PROJECT_NAME)

h2. Utilisation Création d'une base de données (avec comme propriétaire l'utilisateur faisant tourner le code de l'appli)
# su - postgres
$ createdb -O user foobar
Création d'un tenant
$ ./manage.py create_tenant foobar.example.net
[...]
$ ls /var/tmp/foobar/tenants/foobar.example.net/
media  static  templates
Appel des commandes de management
$ manage.py tenant_command createsuperuser -d foobar.example.net
Username (leave blank...)
Visite avec postgresql
$ psql foobar
foobar=> set schema 'foobar_example_net';
SET
foobar=> select username from auth_user;
 username 
----------
 fred
(1 ligne)
...
h2. Fonctionnement tenant_schema, "schémas" dans postgresql, + de notre côté des fichiers dans le filesystem, /var/lib/xxx/tenants/yyy. h2. Lancer des commandes Commande unique:
package-manage tenant_command command -d domain ...
Commande multiple (pour les cron):
package-manage tenant_command command --all-tenants domain ...
h2. Renommage des tenants h3. Renommage d'un site wcs (note: rien à voir avec les tenants Django) * déclarer le domaine et le vhost nginx * se rendre dans le backoffice de wcs @/backoffice/settings/identification/idp/sp@ et @/backoffice/settings/sitename@ et modifier les urls avec le nouveau nom. * renommer le répértoire du tenant * mettre à jour les méta-données dans authentic à partir de la nouvelle url des métadonnées * mettre à jour l'url de base dans le serveur hobo (dans le shell django) * dans l'ancien vhost nginx mettre en place la redirection vers le nouveau nom. h2. Migrations Django Il faut utiliser une commande dédiée pour gérer les migrations sur les tenants. h3. Revenir à la migration d'avant
$ passerelle-manage migrate_schemas iparapheur 0005 -v2
$ passerelle-manage migrate_schemas iparapheur 0005 -v2 --fake  # uniquement en base
h3. Ajouter une migration
$ passerelle-manage makemigrations
$ git add passerelle/contrib/iparapheur/migrations/0006_iparapheur_wsdl_endpoint_location.py
$ passerelle-manage migrate_schemas