Open Stack

Hi Devs,

Considering return request-id to caller specs [1] is implemented in
python-*client, I would like to begin discussion on how these request-ids
will be logged in cross-projects. In logging work-group meeting (11-Nov-2015)
[2] there was a discussion about how to log request-id in the log messages.
In same meeting it wass decided to write oslo.log specs but as of now no specs has been submitted.

I would like to share our approach to log request-ids and seek suggestions
for the same. We are planning to use request_utils module [3] which was
earlier part of oslo-incubator but removed as no one was using it.

A typical use case is: Tempest asking Nova to perform some action and Nova
calling Glance internally, then the linkages might look like this:

RequestID mapping in nova for nova and glance:
---------------------------------------------

INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] Request ID Link: request.link 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43

RequestID mapping in tempest for tempest and nova:
-------------------------------------------------

INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] Request ID Link: request.link 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4' -> Target='nova' TargetId=req-f0fb885b-18a2-4510-9e85-b9066b410ee4

As there is a reference of nova's request-id in tempest and glance's
request-id in nova, operator can easily trace the cause of failure.

Using request_utils module we can also mention the 'stage' parameter to
divide the entire api cycle with stages, e.g. create server can be
staged as start, get-image can be staged as download-image and active instance
can be staged as end of the operation.

Advantages:
-----------

With stages provided for API, it's easy for the operator to find out the failure stage from entire API cycle.

An example with 'stage' is,
Tempest asking Nova to perform some action and Nova calling Glance internally,
then the linkages might look like this:

INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] Request ID Link: request.link.start 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4'

INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] Request ID Link: request.link.image_download 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43

INFO tempest.tests [req-b0df857fb-18a2-4510-9e85-b9435dh8ye4 admin admin] Request ID Link: request.link.end 'req-b0df857fb-18a2-4510-9e85-b9435dh8ye4'

Concern:
--------

As request_utils module is removed from oslo-incubator and this module is
also getting deprecated, I have following options to add it back to OpenStack.

Option 1: Add request_utils module in oslo.log (as it is related to logging
request_ids)
Option 2: Add request_utils module in oslo.utils
Option 3: Add link_request_ids method in utils.py of individual projects.
(this will cause code duplication)

Please let me know your thoughts about the same.

[1] http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
[2] http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-11-11-20.02.log.html
[3] http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.request_utils.html

Thank You,

Abhishek Kekane

______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160301/65b8646a/attachment.html>