Produits Entr'ouvert » Passerelle

Pouvoir choisir de logger ou pas un connecteur ( checkbox infterface connecteur )

if connector.log == True:
  connector.requests = passerelle.utils.RequestSessionWrapper(connector.log)
else
   connector.requests = requests

Dans mon idée, dans une classe de base des connecteurs,

    @property
    def requests(self):
        if self.debug_enabled:
             return passerelle.utils.LoggedRequests()
        else:
             return requests # le module

• le log_level = getattr(... dans requests() ne sert à rien
• j'aurai nommé le logger passerelle.resource.%s.%s' % (slugify(self.__clas__.__name__), self.slug)
• dans LoggedRequest.request() il faut aussi tronquer response.content quand il est passé dans le dico extra

• un espace après % quand on formate une chaîne
• pas de parenthèse autour des arguments à % quand il n'y en a qu'un
• pas d'espace autour de = dans les keyword arguments d'une fonction (install pyflake et cherche le module emacs qui va bien :) )

Il manque les changements au packaging et aux settings par défaut (sinon tout ça ne sert à rien), genre

'loggers': {
   'passerelle.resource': {
      'level': 'DEBUG',
      'propagate': False,
      'handlers': ...,
   },
   ...
}

On met par défaut au niveau DEBUG puisque le vrai niveau se définit maintenant au niveau de chaque ressource.

Par défaut on envoie sur la console et dans les settings debian il faut reprendre la liste des handlers du logger racine venant de debian_config_common.py.

Benjamin Dauvergne a écrit :

• pas d'espace autour de = dans les keyword arguments d'une fonction (install pyflake et cherche le module emacs qui va bien :) )

Il suffit de taper C-x-m-e-c

Voici ce que ça donne

Mar 25 18:01:33 debian DEBUG passerelle.resource.parispocgru.wso2.request: Content-Length:38 Accept-Encoding:gzip, deflate Accept:*/* User-Agent:python-requests/2.7.0 CPython/2.7.11+ Linux/4.3.0-1-amd64 Connection:keep-alive Content-Type:application/x-www-form-urlencoded
Mar 25 18:01:33 debian DEBUG passerelle.resource.parispocgru.wso2.request: content-length:485 server:nginx connection:keep-alive access-control-allow-credentials:true date:Fri, 25 Mar 2016 17:01:33 GMT access-control-allow-origin:* content-type:application/json
Mar 25 18:01:33 debian DEBUG passerelle.resource.parispocgru.wso2.request: '{\n  "args": {}, \n  "data": "", \n  "files": {}, \n  "form": {\n    "stuff": "that is a simple thing", \n    "user": "josh"\n  }, \n  "headers": {\n    "Accept": "*/*", \n    "Accept-Encoding": "gzip, deflate", \n    "Content-Length": "38", \n    "Content-Type": "application/x-www-form-urlencoded", \n    "Host": "httpbin.org", \n    "User-Agent": "python-requests/2.7.0 CPython/2.7.11+ Linux/4.3.0-1-amd64"\n  }, \n  "json": null, \n  "origin": "80.12.92.47", \n  "url": "https://httpbin.org/post"\n}\n'

Tu ne reprends pas la liste des handlers du logger racine, le logger racine c'est celui nommé ''.

Ton exemple de sorti de log c'est avec quel configuration des logs ? Ça ne ressemble pas à ce qu'il y a dans hobo et dans passerelle il n'y a rien non plus on dirait. Surtout je ne comprend pas d'où vient le .request après le passerelle.resource.parispocgru.wso2.

Pour les logs de debug il faudrait peut-être ajouter un texte introductif, genre 'Request headers, ' , 'Response headers, ', 'Response payload', et remplacer 'Payload' par 'Request payload, ' sinon on ne sait pas trop ce qu'on regarde.

En l'état les logs sur les headers sont très difficiles à lire, j'ajouterai un espace après le ':' et peut-être que je séparerai par des pipes juste pour voir (' | ').

Josué Kouka a écrit :

Voici ce que ça donne

Y'a pas l'URL ?

Il faudrait donc l'URL, avec devant le verbe (GET/POST/...) ; mais aussi des indications "Request Headers:", "Request Payload:", "Response Headers:", "Response Payload:" sur les lignes qui suivent...

Benjamin Dauvergne a écrit :

Tu ne reprends pas la liste des handlers du logger racine, le logger racine c'est celui nommé ''.

Normalement le 'handlers': LOGGING['handlers'] le fait. Ah oui t'as raison, faut juste les lister pas, les redefinir

Ton exemple de sorti de log c'est avec quel configuration des logs ? Ça ne ressemble pas à ce qu'il y a dans hobo et dans passerelle il n'y a rien non plus on dirait. Surtout je ne comprend pas d'où vient le .request après le passerelle.resource.parispocgru.wso2.

C'est le resultat de log d'un passerelle en standalone. Le .request vient du fait que le logger est appelé dans la méthod request de @LoggedRequest

Pour les logs de debug il faudrait peut-être ajouter un texte introductif, genre 'Request headers, ' , 'Response headers, ', 'Response payload', et remplacer 'Payload' par 'Request payload, ' sinon on ne sait pas trop ce qu'on regarde.

En l'état les logs sur les headers sont très difficiles à lire, j'ajouterai un espace après le ':' et peut-être que je séparerai par des pipes juste pour voir (' | ').

Thomas Noël a écrit :

Josué Kouka a écrit :

Voici ce que ça donne

Y'a pas l'URL ?

Il faudrait donc l'URL, avec devant le verbe (GET/POST/...) ; mais aussi des indications "Request Headers:", "Request Payload:", "Response Headers:", "Response Payload:" sur les lignes qui suivent...

J'avais juste pas coller les méthodes

request_reponse ?

La méthode n'est pas passé dans le dico extra.

Concernant les logs précédents je ne vois pas quelle chaîne de formatage fait que la fonction est ajoutée au domaine des log, tu pourrais regarder ?

Ack.

Euh non pas ack, je veux bien des tests utilisant pytest-capturelog, merci.

Ton test dépend d'un appel à httpbin, regarde du coté de https://pypi.python.org/pypi/httmock/ pour éviter ça.

from httmock import urlmatch, HTTMock

@urlmatch(netloc=r'httpbin\.org$')
def httpbin_mock(url, request):
    return 'Feeling lucky, punk?'

with HTTMock(httpbin_mock):
    response = requests.post(url, json={'name':'josh'})

Il faut ajouter httmock aux dépendance tox aussi.

Ack.

J'attends la fin du POC Paris pour pouvoir pouser (Normalement demain dans l'après midi)

https://jenkins.entrouvert.org/job/passerelle/1291/changes

self = <django.db.backends.sqlite3.base.SQLiteCursorWrapper object at 0x35308a0>
query = 'SELECT "fake_family_fakefamily"."id", "fake_family_fakefamily"."title", "fake_family_fakefamily"."slug", "fake_family...vel", "fake_family_fakefamily"."jsondatabase" FROM "fake_family_fakefamily" ORDER BY "fake_family_fakefamily"."id" ASC'
params = ()

    def execute(self, query, params=None):
        if params is None:
            return Database.Cursor.execute(self, query)
        query = self.convert_query(query)
>       return Database.Cursor.execute(self, query, params)
E       OperationalError: no such column: fake_family_fakefamily.log_level

.tox/coverage-django18/local/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py:485: OperationalError

Tu aurais du le voir en lançant les tests il me semble.

Patch poussé: build back to normal

commit cf64834eab3690aa74206ae3e4f25750dee9ab68
Author: Serghei Mihai <smihai@entrouvert.com>
Date:   Wed Apr 6 19:08:10 2016 +0200

    logging: add missing migrations for 'log_level' attribute (#10299)

Benjamin Dauvergne a écrit :

https://jenkins.entrouvert.org/job/passerelle/1291/changes

[...]

Tu aurais du le voir en lançant les tests il me semble.

Désolé, j'avais des apps non activé malheureusement. Je serai plus prudent les prochaines fois

Serghei Mihai a écrit :

Patch poussé: build back to normal
[...]

Merci