DRY transport request logging

[Kurt Griffiths]

At the top of the request responders in the transport driver we have some LOG.debug(...) code that could be DRY'd up using hooks/decorators.

[Kurt Griffiths (kgriffs)]

Related: consider formatting structured data in our log messages as JSON rather than comma-delimited.

[Flavio Percoco (flaper87)]

@flwang are you working on this? If not, would you mind removing yourself from the assigned field?

[Nate Johnston (nate-johnston)]

Files to update:

zaqar/transport/auth.py
zaqar/transport/wsgi/utils.py
zaqar/transport/wsgi/v1_0/claims.py
zaqar/transport/wsgi/v1_0/messages.py
zaqar/transport/wsgi/v1_0/metadata.py
zaqar/transport/wsgi/v1_0/pools.py
zaqar/transport/wsgi/v1_0/queues.py
zaqar/transport/wsgi/v1_0/stats.py
zaqar/transport/wsgi/v1_1/claims.py
zaqar/transport/wsgi/v1_1/flavors.py
zaqar/transport/wsgi/v1_1/messages.py
zaqar/transport/wsgi/v1_1/pools.py
zaqar/transport/wsgi/v1_1/queues.py
zaqar/transport/wsgi/v1_1/stats.py
zaqar/transport/wsgi/v2_0/claims.py
zaqar/transport/wsgi/v2_0/flavors.py
zaqar/transport/wsgi/v2_0/messages.py
zaqar/transport/wsgi/v2_0/pools.py
zaqar/transport/wsgi/v2_0/queues.py
zaqar/transport/wsgi/v2_0/stats.py
zaqar/transport/wsgi/v2_0/subscriptions.py
zaqar/transport/wsgi/v2_0/urls.py

I queried #openstack-zaqar: "I was wondering if I should create a new file to contain the requested decorator, or should I add it to an existing file, like transport/base.py? I'm just not familiar enough with the codebase - yet - to know if there's a natural home for this."

Waiting on that answer to continue implementing.

[Nate Johnston (nate-johnston)]

The preferred implementation for a decorator like this is in zaqar/common/decorators.py, so I am adding my decorator there. have added the decorator to functions in zaqar/transport/wsgi/v1_0/claims.py, and I am currently trying to get tox to test properly. My debate at the moment is this - the decorator needs to know 3 pieces of data, which are arguments 2, 3, and 4 to the function being decorated; should the decorator pull out args[2], args[3], and args[4] to retrieve them, which might break in the future if arguments are reordered, or should it take those things as parameters? I am inclined towards the latter, I think.

Anyhow, I will try to get mongodb working so I can test this properly. If I can't I may push up my changes and see how they work in the gate. The error that mongodb is dying with on startup is:

2015-09-15T14:01:15.146+0000 SEVERE: Failed global initialization: UnknownError assertion src/mongo/db/server_options_helpers.cpp:355

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/224882

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/224882
Committed: https://git.openstack.org/cgit/openstack/zaqar/commit/?id=8b86f12fda6395befc5de56676fed645d40245c1
Submitter: Jenkins
Branch: master

commit 8b86f12fda6395befc5de56676fed645d40245c1
Author: Nate Johnston <email address hidden>
Date: Thu Sep 17 19:54:37 2015 +0000

    Use decorator instead of request logging in responders

    Replace log lines in each request responder in the transport
    driver with a decorator, removing needlessly repeated code.

    Depends-On: Ifb4208e2e1dba6f2c5954bb12a1c768d86453f0e

    Closes-bug: #1288406

    Change-Id: Ib3216ebcc9a239339ec11b6b4292fa308511f820