h1. Jupiter and Beyond the Infinite

Faire en sorte que hobo couvre le déploiement des tenants.

h1. On intègre du code dans hobo

* les composants de déploiement des applications (y compris les détails pour chaque type de composant) [sauf peut-être pour w.c.s. qui a déjà sa mécanique, mais bon, on verra]

* la gestion entr'ouvert des multitenants, basée sur django-tenant-schema mais avec stockage de configuration dans le filesystem (= on retire ça de python-entrouvert), avec les commandes :
** create_tenant www.example.net
** migrate_tenants
** list_tenants
** tenant_command --domain www.example.net command

* les middleware de configuration selon les tenants, par exemple :
** hobo.middleware.settings.mellon  (config des idp dans un sp mellonisé)
** hobo.middleware.settings.authentic2 (config des clés SAML dans un A2)
* le middleware pour les templatesvars :
** hobo.middleware.context.vars (création des templatesvars)

h2. Ça donnerait ça :

@hobo@

> le serveur de déploiement : gestion de l'environnement dans le /manage et envoi du hobo.json correspondant dans celery

@hobo.multitenant@

> reprendre entrouvert.djommon.multitenant (fait avec conservation de l'historique, dans la branche wip/merging-multitenant de hobo, #6468)

@hobo.agent@

> réception du hobo.json dans le celery, déploiement de tous les services correspondant via l'appel de commandes de ce genre :
>   sudo -u service /usr/lib/service/manage.py hobo_deploy www.example.net < hobo.json

@hobo.agent.authentic2@

> ne contient que la commande de management hobo_deploy dédiée au déploiement d'un tenant authentic2 :
>* create_tenant
>* création de la bi-clé SAML dans le tenant (saml.crt, saml.key)
>* copie du hobo.json reçu dans tenant/www.example.net/hobo.json
>* ajout des policies par défaut
>* download des metadonnées dans federation.xml
>* sync-metadata de federation.xml
> Cette application est à ajouter dans le INSTALLED_APPS (ou SHARED_APPS) d'authentic2 pour lui donner cette commande hobo_deploy

@hobo.agent.common@

> ne contient que la commande de management hobo_deploy dédiée au déploiement d'un SP mellonisé :
>* create_tenant
>* copie du hobo.json reçu dans tenant/www.example.net/hobo.json
>* download des metadonnées de l'idp dans tenant/www.example.net/metadata_idp_0.xml
> Cette application est à ajouter dans le INSTALLED_APPS (ou SHARED_APPS) du SP cible (combo, passerelle, ...) pour lui donner la commande hobo_deploy

@hobo.middleware.settings.mellon@

> configuration des settings.MELLON* depuis les données de tenant/www.example.net/metadata_idp_0.xml et le hobo.json si besoin

@hobo.middleware.settings.authentic2@

> configuration des settings.SAML* depuis saml.crt et saml.key

@hobo.middleware.context.vars@

> création des templatesvars depuis le hobo.json du tenant

h1. Processus de création d'un tenant

Le celery client reçoit un environnement hobo.json. Pour chaque tenant de chaque service listé dans cet environnement, il lance la commande de déploiement du service. Pour un service djangoisé, c'est typiquement :

  @sudo -u service /usr/lib/service/manage.py hobo_deploy www.example.net < hobo.json@

Ce "hobo_deploy" va lancer la commande de management programmée dans hobo/agent/<service>/management/commands/hobo_deploy.py

h1. Processus de mise à jour d'un tenant

Le processus de création est configurer pour gérer un tenant qui existe déjà, et ne rien faire dans ce cas, juste mettre à jour le hobo.json, et s'il est différent mettre à jour les métadonnées, etc. Ces mises à jour sont prises en compte aussitôt par le tenant via les middlewares.


h2. Notes de RER que bof

hobo pourrait fournir: @from hobo.helper.settings.mellon import * # config de base MELLON ouaip bon bofff@