Produits Entr'ouvert » Hobo

Je reprends la discussion ici, pour le module on a choisi de mettre ça dans le urls.py de hobo (si ozwillo est dans installed_apps).
Pour les fichiers de template, ils seront dans /etc/hobo/ozwillo (pour ceux en écriture) et j'écrirai les recipe et imports combo avec les redirect_url modifiés dans des fichiers temporaires avec tempfile.

Je vais aussi ajouter un README pour préciser les variables à déclarer dans le settings.json (secret d'instanciation, domaine de l'environnement etc).

Pour les urls c'est mieux de faire avec l'option pointée par benj dans #14931 ou la solution ici est suffisante ?
Je ne me rends pas compte si l'une est plus acceptable que l'autre ou pas?

Jean-Baptiste Jaillet a écrit :

Pour les urls c'est mieux de faire avec l'option pointée par benj dans #14931 ou la solution ici est suffisante ?
Je ne me rends pas compte si l'une est plus acceptable que l'autre ou pas?

Selon moi la solution pointée par Benj est pareille, mais je trouve que vérifier le installed_apps revient exactement au même, et évite de poser une variable dans le settings.

• return('Invalid HMAC algo') => utiliser HttpResponseForbidden comme au dessus
• idem pour return('No HMAC in the header')
• ça sert à rien de mettre des "ret_code =" si ret_code n'est pas utilisé. Idem pour r=request.post final
• pour les open('xxx.json') : ça va pas marcher, il faut donner un chemin complet, je t'ai proposé /etc/hobo/ozwillo/*
• et quand template_recipe.json n'existe pas, faire que tes vues renvoies un 404 (ie "le provisionning ozwillo n'est pas actif ici, merci)" ; tu peux faire un petit décorateur @if_ozwillo_enabled pour tes vues pour ça.
• ajouter des logger.debug pour voir ce qui est reçu, renvoyé, etc
• indenter import-site.json
• un petit README qui explique ce qu'il faut mettre dans /etc/hobo/ozwillo/ et dans les settings

une fois cette première passe faite on ajoutera le packaging pour placer README et templates dans un /usr/share/doc/hobo/ozwillo/

Enfin une remarque plus générale : le "cook" ça ne se termine pas toujours bien, ça timeout assez facilement. Je doute que cette machinerie fonctionne dans la vraie vie.

Jean-Baptiste Jaillet a écrit :

Le README semble à peu près clair (je vois juste pas comment on mets le INSTALLED_APPS dans le settings.json).

Parce qu'on peut pas ;) Les INSTALLED_APPS c'est toujours dans le «vrai» settings -- en l'occurence ça sera /etc/hobo/settings.py, avec un ajout aussi dans les TENANT_APPS ; mais dans le README il suffit de dire « ajouter 'hobo.contrib.ozwillo' dans settings.INSTALLED_APPS ».

    with io.open(combo_file_path, 'w', encoding='utf-8') as f:
        f.write(unicode(json.dumps(imp_site_template, ensure_ascii=False)))

C'est mignon mais on peut aussi jouer les vieux et laisser le module produire de l'ascii.

Il reste encore les "io.open" et là dessus, ma foi, je veux bien un conseil (pour éviter d'avoir un d\x09marches un truc dans le style au lieu de démarches).

Tu veux dire que tu es gêné quand tu ouvres un fichier json dans ton éditeur et que tu y lis "d\u00e9marches" (réponse : faut pas être gêné), ou c'est autre chose ?

c'est bien ça Fred, je note donc que ce n'est pas un souci

OK. Comme je le disais plus tôt, et vu avec Benj, je mettrai le commit sur la branche de dev puis je ferai le patch rebasé avec la branche master

Hop je veux bien une relecture sur http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=e19652d642bd65d8f28e81d88bfc4e7089203fbb (destruction d'instance).
J'ai choisi de mettre les différents services avec les bases et prefix dans un dictionnaire de settings, pour simplifier en cas d'ajout ou retrait de serivce.

subprocess.call(['sudo', '-u', 'postgres', 'dropdb', 'wcs_%s' % (schema)]) et l'autre appel, sur les machines où la db n'est pas locale ?

exact. Je suis resté sur la conf dev / locale. Je change ça.

Bon j'ai pas mal regardé et j'ai eu des soucis en essayant de me connecter à distance via les commandes postgres sur la recette (il me demande un mot de passe pour le compte postgres et je n'ai pas les droits avec hobo, même en ayant fait le sudoers spécifique). Donc l'autre solutions c'est que chaque brique se connecte avec son mot de passe qui est dans les settings, mais ça me semble cavalier puisqu'il faudrait faire autant de runscript que de brique à détruire.

Serghei m'a parlé de l'objet Tenant, qui a sa méthode Delete et qui gère du coup la partie connexion avec la base, le souci que j'ai ici et que je n'ai su résoudre c'est que le tenant qui execute la code (pour le sictiam le tenant whatever-sve.sictiam.dev.entrouvert.org) doit détruire un autre tenant => Serghei m'a parlé ici aussi du with tenant_context.
J'ai toute confiance en Serghei, si j'écris ici c'est pour une piste / aide en groupe sur la manière de faire, et une explication si on choisi la solution de passer par les objets tenants et non des commandes postgres appelées en subprocess.call. (explication sur with tenant_context, comment on l'utilise, comment récupérer des tenants autres que celui dans lequel le code s'éxecute etc).

Jean-Baptiste Jaillet a écrit :

Bon j'ai pas mal regardé et j'ai eu des soucis en essayant de me connecter à distance via les commandes postgres sur la recette (il me demande un mot de passe pour le compte postgres et je n'ai pas les droits avec hobo, même en ayant fait le sudoers spécifique). Donc l'autre solutions c'est que chaque brique se connecte avec son mot de passe qui est dans les settings, mais ça me semble cavalier puisqu'il faudrait faire autant de runscript que de brique à détruire.

Ajouter une commande delete-tenant qui fait un Tenant.delete().

Serghei m'a parlé de l'objet Tenant, qui a sa méthode Delete et qui gère du coup la partie connexion avec la base, le souci que j'ai ici et que je n'ai su résoudre c'est que le tenant qui execute la code (pour le sictiam le tenant whatever-sve.sictiam.dev.entrouvert.org) doit détruire un autre tenant => Serghei m'a parlé ici aussi du with tenant_context.

Oui d'où une commande dans hobo, sur le même modèle que create_tenant.

J'ai ouvert le ticket et je te l'ai assigné, go go go, #15513.

Mise à jour avec les derniers commit pour la création de l'instance (je vais mettre la jour la destruction avec les nouvelles commandes de destructions de tenant).
J'ai rebasé les commits pour que la destruction soit le dernier (dernier commit pour la création : http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=d2c07afd90b2d3ace424009c794e685f585e2ab8)

Il y a des détails de l'historique, des corrections d'erreur, dont on n'a que faire à la relecture, dont la présence en commits distincts est inutile.

Sans même les lire, a minima, ceux qui touchent moins de dix lignes. Mais de manière plus générale tout ce qui est "fix". (on se fout de savoir que le truc n'était pas parfait du premier coup et qu'il a fallu corriger et corriger et corriger), on veut juste relire la version qui tient la route.

Par ailleurs, ton commentaire est à 17h00 pile et à la même heure on a une trace

Subject: [hobo] ERROR: Error occured while deploying ozwillo instance dimebag

C'est vraiment bon ?

Hum en effet j'ai vu la trace et j'ai relancé deux tests je n'ai pas eu de souci.

The BadStatusLine exception is raised when you call urllib2.urlopen(url) and the remote server responds with a status code that python cannot understand.
Assuming that you don't control url, you can't prevent this from happening. All you can do is catch the exception, and manage it gracefully.

Pour les commits j'hésitais à rebaser mais du coup j'ai mas réponse. Je remets tout ça dans un seul commit

Ok rebasage fait et pousser, commit http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=81932983ed31d007da274996283c559dd3ea7762

+#create agent_sve role
+ou = OrganizationalUnit.objects.get(default=True)
+role, created = Role.objects.get_or_create(uuid='3f3367d817bb4a9aa98e7ed6c83b5b09',
+                                           defaults={'name': u'Agents SVE', 'ou': ou})

J'ai regardé recette et prod et elles n'ont pas de rôle "Agents SVE". Il doit servir à quoi ? Pourquoi en forcer l'uuid ?

(à suivre)

En fait donc, "Agents SVE" (et ce patch en général), ça concerne le déploiement de nouvelles instances, pas l'instance "SVE" générale. Mais sur des instances existantes, genre sospel.test, le rôle "Agents SVE", il a pas cet uuid.

Et l'uuid en question, 3f3367d817bb4a9aa98e7ed6c83b5b09, c'est parce que le modèle de site w.c.s. utilisé vient avec déjà utilisé/provisionné ce rôle avec cet uuid. (bon, honnêtement pas fan, mais laisser pisser).

+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+import os

On me dira que c'est juste du style que ça n'a aucune espèce d'importance mais vraiment, a-t-on d'autres fichiers où le code suit sans ligne vide la licence ?

+from unidecode import unidecode

C'est une nouvelle dépendance et elle n'est déclarée nulle part et faudrait juste utiliser le slugify de django.

+def is_ozwillo_enabled(func):
+    def wrapper(request):
+        if not os.path.exists('/etc/hobo/ozwillo'):

Ça oblige tous les hobo d'un site à gérer ozwillo, un getattr(settings, 'OZWILLO_ENABLED', False) éviterait ça.

Dans la série, encore plus à laisser pisser, c'est dommage d'utiliser /etc/hobo/ plutôt que le répertoire du tenant.

+    if 'organization_name' not in data.keys():
+        return HttpResponseBadRequest('Missing parameter "instance_name"')

Un minimum d'attention.

+
+
+

Parfois des lignes vides, pour respirer.

+        template_recipe = json.load(open('/etc/hobo/ozwillo/template_recipe.json', 'rb'))
+        var = template_recipe['variables']
+        for key, value in var.items():
+            var[key] = value.replace('instance_name', instance_name)

Ce jeu du chercher/remplacer serait inutile avec une étape "load-variables-from". Le recipe.json serait copié dans un répertoire temporaire et dans le même répertoire temporaire un fichier avec les variables serait créé et le recipe.json contiendrait "load-variables-from": "recipe-variables.json". Laisser pisser.

+        imp_site_template = json.load(open('/etc/hobo/ozwillo/import-site-template.json', 'r'))
+
+        for row in imp_site_template:
+            row['fields']['redirect_url'] = row['fields']['redirect_url'].replace('instance_name', instance_name)

Ce jeu du chercher/remplacer serait inutile en utilisant [connexion_url], [eservices_url] et cie dans les redirect_url du fichier.

+            f.write(unicode(json.dumps(imp_site_template)))

Utilisation inutile d'unicode().

+        subprocess.call(...

Utiliser check_call, pour que ça éclate si la commande éclate.

+      {
+         "create-superuser" : {
+           "username" : "admin",
+           "email" : "admin@example.net" 
+         }
+      },

Il y a un compte admin qui est créé via create_user_ozwillo.py, pourquoi en créer un autre ici ?

+    if new_user.email != email_address:
+        new_user.email = email_address
+        new_user.save()
+    if new_user.ou != provider.ou:
+        new_user.ou = provider.ou
+        new_user.save()
+    if not new_user.is_superuser:
+        new_user.is_superuser = True
+        new_user.save()
...

Payé à la ligne ? À remplacer par du code qui met tous les attributs tout le temps aux nouvelles valeurs et qui fait un .save() au bout.

+            logging.info('provisionned with uuid %s', new_user.uuid)
...
+logging.info('ozwillo provisionning: new admin with email %s and sub %s',
+             email_address, user_id)
...
+logging.info('owzillo provisionning: user created with uuid: %s', user.uuid)

Pour la création d'un utilisateur, une seule ligne de log ?

Tout fonctionne en dehors du [idp_url] qui ne fait pas d'erreur mais me laisse sur la page combo user.
Si je mets une valeur random j'ai bien une erreur, et idp est bien le slug de l'authentic de l'instance.

Bon je peux mettre le commit étant donné que ce souci est sur un fichier static plus que vraiment du code.
http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=ce97fc2a219e7370efe747cd4aa7752eefcc4ffe (avec les remarques prises en compte)

Tout fonctionne en dehors du [idp_url] qui ne fait pas d'erreur mais me laisse sur la page combo user.

Une URL pour constater ça ?

Oui pardon https://genji.sictiam.dev.entrouvert.org/

Un lien sur "Mon compte" envoie bien vers https://connexion-genji.sictiam.dev.entrouvert.org/

Et la page d'accueil d'authentic, elle envoie vers l'accueil de combo.

Manque le /accounts/

...

Ok c'est corrigé ça fonctionne (http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=f9044c09ea0ac679fe86513c0782ac4c365ca40c avec mise à jour)

Il y a un imp_site_template qui existe pour rien.

Comment diable cela peut-il fonctionner sans erreur ? Il y a os.remove(combo_file_path) alors que combo_file_path n'est pas défini.

+        with open(recipe_file_path, 'w') as f:
+            f.write(json.dumps(template_recipe))

json.dump existe pour écrire directement dans un fichier.

Oui pardon je me suis emmêler les pinceaux, c'était modifié en dev, j'étais plus en sync.
J'ai modifié le json.dump.

http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=e4bc77d6a76d169941b88981eaab97c96a007e92

(je vais mettre la jour la destruction avec les nouvelles commandes de destructions de tenant)

Faire ça. Puis taper le tout en un seul commit.

Exécuter pylint ou équivalent sur le fichier et corriger les trucs élémentaires (genre imports pas utilisés (à l'œil, io et rmtree, déjà), des espaces absents (genre après 'redirect_uris'), etc.).

+    new_user.first_name = 'admin'
+    new_user.last_name = 'ozwillo'

Ça alors que le message d'ozwillo fournit un nom pour la personne :

  "user": {
    "email_address": "mates@entrouvert.com", 
    "id": "7b3c9430-33b6-4d4c-b08b-1bc00f85526f", 
    "name": "mates" 
  }

Il faudrait plutôt utiliser le name qu'on peut ici récupérer. Peut-être mettre ça dans prénom et "(admin ozwillo)" dans nom ?

[...]
+        requests.post(registration_uri, data=json.dumps(services), auth=(client_id, client_secret), headers=headers)

Tant qu'à logguer mille trucs, la réponse finale d'ozwillo pourrait l'être aussi.

Ok, je vais surement laisser juste 'admin + prenom' du coup c'est plus logique.

Pour le log de la réponse je log l'objet request ou uniquement le dico que j'envoie? (si c'est la cas c'est loggé plus haut, le dictionnaire service).

Et pour finaliser la destruction je veux bien une trame ou un petit coup de main sur #15636.

Pour le log de la réponse je log l'objet request ou uniquement le dico que j'envoie? (si c'est la cas c'est loggé plus haut, le dictionnaire service).

Il y a un POST qui est fait vers ozwillo et là-dessus il y a ozwillo qui répond quelque chose et bien c'est ça que j'appelle la réponse finale d'ozwillo.

http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=71583087937dd8f492aab8380b05c9bff14a1c13

Avec les commentaires et l'ajout du modèle + test sur l'existence d'une instance avec un nom similaire (en relisant je me suis dis que j'aurais pu mettre un primary_key sur le instance_name et catcher l'exception à la création mais bon). Testé sur des déploiements en dev. La destruction est encore séparée du commit. Je mets à jour (la destruction avec les nouvelles commandes et nouveau modèle), on valide et je fusionne les deux.

+class OzwilloInstance(models.Model):
+    instance_name = models.CharField(max_length=250, verbose_name=_('instance name'))
+    instance_id = models.CharField(max_length=450, verbose_name=_('instance id'))

Je zappe la discussion sur la longueur max, simplement vire les verbose_name, ce n'est jamais présenté, épargnons-nous en la traduction.

+    if OzwilloInstance.objects.filter(instance_name=org_name):

L'unicité doit être posée sur l'instance_id, pas sur le nom.

+        call_command('cook', recipe_file_path)

Encore vu des traces tout à l'heure, tu as ajouté la prise en charge d'un paramètre de timeout, tu ne l'utiliserais pas ?

+    OzwilloInstance.objects.create(instance_id=data['instance_id'], instance_name=org_name)

C'est l'org_name qui est stocké ici, mais un peu plus loin ça sera pris comme étant partie du nom de domaine, oubliant qu'à la création il y aura eu un (amusant) instance_name = slugify(instance_name.lower().replace(' ', '-')).

Pour la destruction http://repos.entrouvert.org/hobo.git/commit/hobo?h=wip/ozwillo&id=54d30db0e1546d996c0a1ee9628dbf148fc9f4b9. Il faut que je finisse les tests sur le tickets de la commande de destruction d'un tenant wcs (mais la commande marche, j'ai testé les cas avec et sans force-drop). J'ai détaillé un peu la structure du dictionnaire service dans le README, manière la plus élégante que j'ai trouvé pour automatiser sans tout écrire en dur dans le code.

Fred pour les remarques du haut:

"L'unicité doit être posée sur l'instance_id, pas sur le nom." => Le problème que ça me posais quand je l'ai fait, c'est que l'id va changer à chaque fois, hors si une personne mets le même nom, ou reclique par erreur ou je ne sais, ça va écraser tous les nouveaux formulaires qu'ils ont créés + combo. Donc je préfère vérifier le nom (après si on dit cette erreur c'est pas à nous de la gérer ok).

Pour le cook, en effet, je l'ai ajouté à la main sur la dev la dernière fois et là aussi du coup, my bad, je rajoute ça dans le code (avant de le faire j'ai mis 360).

Pour les verboses ok.

Pour le slugify de l'instance_name en effet, j'ai fait mes tests en mettant des noms en minuscules, sans espaces ou tirets. Je corrige ça.

"L'unicité doit être posée sur l'instance_id, pas sur le nom." => Le problème que ça me posais quand je l'ai fait, c'est que l'id va changer à chaque fois, hors si une personne mets le même nom, ou reclique par erreur ou je ne sais, ça va écraser tous les nouveaux formulaires qu'ils ont créés + combo. Donc je préfère vérifier le nom (après si on dit cette erreur c'est pas à nous de la gérer ok).

Ok, c'est donc les champs qui ont des noms très étranges par rapport à leur fonction, instance_name, c'est une information locale, qui est en fait "slug utilisé dans la constitution du nom de domaine", et instance_id, c'est un identifiant externe; je pense que ça serait bien plus clair si instance_name devenait genre domain_slug (à marqué comme devant être unique) et instance_id devenait external_ozwillo_id.

#15752 étant désormais présent, il faudrait en profiter dans l'appel à cook.

Ok http://repos.entrouvert.org/hobo.git/commit/hobo?h=wip/ozwillo&id=dd9f709bae45988778ed38ce8b70d58b2c8d3885.

J'en ai profité pour ajouter des logs lors de la destruction (y'a pas de raison) et j'ai tout mis dans un seul commit.
Les remarques précédentes ont été prises en compte.

#15752 étant désormais présent, il faudrait en profiter dans l'appel à cook.

Commentaire ignoré. Je ne regarde même pas le reste.

+            #to get the two combo instances which have same service
+            service = s.split('_')[0]
+
+            tenant = '%s%s.%s' % (infos[0], instance, settings.OZWILLO_ENV_DOMAIN)
+
+            subprocess.check_call(['sudo', '-u', service, infos[1],
+                             'delete_tenant', '--force-drop', tenant])

Donc dans la variable service c'est en fait l'utilisateur qui doit exécuter la commande, et donc combo_usager et combo_agent hop ça permet d'avoir combo. Ok. (non)

Plutôt faire évoluer OZWILLO_SERVICES pour que chaque service à déployer ait son dictionnaire, avec l'information détaillée, genre :

OZWILLO_SERVICES = [
   {"prefix": "connexion-",
    "command": "authentic2-multitenant-manage",
    "user": "authentic-multitenant"},
   {"prefix: "",
    "command": "combo-manage",
    "user": "" 
   }
   ...
]

Puis se dire que cette info, on l'a déjà et tenter de réduire le tout à :

from hobo.agent.worker import settings as worker_settings
...

OZWILLO_SERVICES = [('connexion-', 'authentic'), ('agents-', 'combo'), ...]
...

for prefix, service in OZWILLO_SERVICES: # tiens pourquoi ça s'appelle pas PUBLIK_SERVICES ?
    cmd = getattr(worker_settings, '%s_MANAGE_COMMAND'  % service.upper())
    subprocess.check_call(cmd + ...)

Bien sûr ça pourrait ne pas marcher, notamment je ne sais pas le mail que peux faire l'import celery dans le worker/__init__.py; bref, ne tentons même pas vu le temps déjà passé ici.

Et donc rewind,

Donc dans la variable service c'est en fait l'utilisateur qui doit exécuter la commande, et donc combo_usager et combo_agent hop ça permet d'avoir combo. Ok. (non)

Appeler la variable "service" différemment, vu qu'on y met en fait le nom de l'utilisateur, ça serait déjà ça de pris pour la compréhension.

http://repos.entrouvert.org/hobo.git/commit/hobo?h=wip/ozwillo&id=700f2c22d4dfad1a43b47795b6f1648e304cd93e

Sur create_user_ozwillo.py, il a été noté dans #13471 que prénom/nom ne sont pas corrects (admin borihuela vs Benoit Orihuela), en attente là d'une réponse.

Ce ticket dépend aussi de #15636 qui a encore une volée de remarques.

Et ici-même, encore et toujours des erreurs de style, genre espace manquant ici :

+                'service_uri':'https://connexion-%s.%s/accounts/oidc/login?iss=%s'

(sans même parler du pâté illisible qu'est l'appel à oidc-register-issuer).

je vais modifier les erreurs de style.
Pour le pâté illisible de oidc-register-user, avant que je génère des soupirs inutiles, je pourrais le rendre plus lisible en revenant à la ligne pour chaque argument + valeur ?

Oui, vague exemple sur une autre,

        subprocess.check_call(['sudo', '-u', 'authentic-multitenant',
                               'authentic2-multitenant-manage', 'tenant_command', 'runscript', '-d',
                               'connexion-%s.%s' % (instance_name, settings.OZWILLO_ENV_DOMAIN),
                               '/usr/lib/python2.7/dist-packages/hobo/contrib/ozwillo/scripts/create_user_ozwillo.py',
                               user['email_address'], user['id'], user['name']])

pourrait devenir :

        domain_name =  'connexion-%s.%s' % (instance_name, settings.OZWILLO_ENV_DOMAIN)
        create_user_script = ... # créé en fonction de la localisation du module hobo.contrib.ozwillo
        subprocess.check_call([
            'sudo', '-u', 'authentic-multitenant',
            'authentic2-multitenant-manage',
            'tenant_command', 'runscript', '-d', domain_name,
            create_user_script, user['email_address'], user['id'], user['name']
            ])

• les chaines "complexes" sont créées avant
• les lignes sont alignées sur leurs rôles
  • 1) on comprend que la commande sera exécutée en tant que l'utilisateur authentic-multitenant
  • 2) on voit quelle commande va être lancée
  • 3) on voit que c'est un script lancé sur le domaine donné
  • 4) on voit que c'est tel script avec tels paramètres

J'ai poussé les modifs de style, et re testé sur la dev.
http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo

+email_address = args[1]
+user_id = args[2]
+user_name = args[3]
+
+def create_user(user_id, email_address):
...
+    new_user.email = email_address
+    new_user.last_name = user_name

Va comprendre à la lecture que le user_name il vient des arguments passés lors de l'appel alors que le email_address vient du paramètre passé à la fonction (qui in fine plus tard se révélera être tiré aussi de la ligne de commande).

+    org_name = slugify(data['organization_name'].lower().replace(' ', '-'))

Le slugify il fait déjà justement la mise en minuscules et le remplacement des espaces par des tirets. (je pointais ça comme "amusant" sans préciser plus haut)

+    logger.debug('data sent for destruction : %r' % data)

Répété mille fois, pas d'espace avant les :.

+      {
+         "create-passerelle" : {
+            "url" : "https://${passerelle}/",
+            "title" : "Passerelle" 
+         }
+      },
+      {
+            "set-theme" : {
+                          "theme" : "publik" 
+                       }
+      }

Toujours de l'indentation fantaisie.

J'imagine bien qu'à un moment il faudrait que j'abandonne l'affaire, mais faut peut-être demander un ack à quelqu'un d'autre, moi j'ai encore bien du mal.

Modifications faites : http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=b69172fab04906f186f2111973c33b0f35f2a40f

J'ai poussé ma relecture sur ta branche, http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo&id=e054e4ca61ff712c32d133c25c94ce4d165f1bb0

Pas de .pop(), faut passer les chaînes de log en unicode (parce que ça marche mieux), faut éviter de trop indenter et donc au lieu de faire de grand try/catch faite une première fonction qui contient juste le try/catch et appelle la suivante, dans ce genre de code c'est bien de préfixer les logs avec un entête ici ozwilllo, aussi faut pas en mettre des tonnes dans les logs, garder un style (là des fois des majuscules, des fois pas), request/response pas request/answer, dans les méthodes de log pas besoin d'utiliser l'opérateur %, tous les paramètre sont interpolés dans la chaîne principale.

Je pense que c'est poussable mais faudrait tester un peu quand même avec ces modifications.

Testé sur la dev. Tout marche bien.
J'ai fait des modifs (le slugify modifié n'était pas passé et sur l'homogénéisation des majuscules minuscules dans les erreur 400).

C'est tout dans un seul commit : http://repos.entrouvert.org/hobo.git/commit/?h=wip/ozwillo

Ack. Mais t'as raté quelques majuscules sur les 400.

ok je change les 400 et je pousse.