
<html dir="ltr">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>

</head>

<body ocsi="0" fpstyle="1">

<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi Devs,<br>

<br>

Considering return request-id to caller specs [1] is implemented in<br>

python-*client, I would like to begin discussion on how these request-ids<br>

will be logged in cross-projects. In logging work-group meeting (11-Nov-2015)<br>

[2] there was a discussion about how to log request-id in the log messages.<br>

In same meeting it wass decided to write oslo.log specs but as of now no specs has been submitted.<br>

<br>

I would like to share our approach to log request-ids and seek suggestions<br>

for the same. We are planning to use request_utils module [3] which was<br>

earlier part of oslo-incubator but removed as no one was using it.<br>

<br>

A typical use case is: Tempest asking Nova to perform some action and Nova<br>

calling Glance internally, then the linkages might look like this:<br>

<br>

RequestID mapping in nova for nova and glance:<br>

---------------------------------------------<br>

<br>

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<br>

<br>

RequestID mapping in tempest for tempest and nova:<br>

-------------------------------------------------<br>

<br>

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<br>

<br>

As there is a reference of nova's request-id in tempest and glance's<br>

request-id in nova, operator can easily trace the cause of failure.<br>

<br>

Using request_utils module we can also mention the 'stage' parameter to<br>

divide the entire api cycle with stages, e.g. create server can be<br>

staged as start, get-image can be staged as download-image and active instance<br>

can be staged as end of the operation.<br>

<br>

Advantages:<br>

-----------<br>

<br>

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

<br>

An example with 'stage' is,<br>

Tempest asking Nova to perform some action and Nova calling Glance internally,<br>

then the linkages might look like this:<br>

<br>

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

<br>

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<br>

<br>

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

<br>

Concern:<br>

--------<br>

<br>

As request_utils module is removed from oslo-incubator and this module is<br>

also getting deprecated, I have following options to add it back to OpenStack.<br>

<br>

Option 1: Add request_utils module in oslo.log (as it is related to logging<br>

request_ids)<br>

Option 2: Add request_utils module in oslo.utils<br>

Option 3: Add link_request_ids method in utils.py of individual projects.<br>

(this will cause code duplication)<br>

<br>

Please let me know your thoughts about the same.<br>

<br>

[1] http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html<br>

[2] http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-11-11-20.02.log.html<br>

[3] http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.request_utils.html<br>

<br>

Thank You,<br>

<br>

Abhishek Kekane<br>

</div>

<br clear="both">

______________________________________________________________________<BR>

Disclaimer: This email and any attachments are sent in strictest confidence<BR>

for the sole use of the addressee and may contain legally privileged,<BR>

confidential, and proprietary data. If you are not the intended recipient,<BR>

please advise the sender by replying promptly to this email and then delete<BR>

and destroy this email and any attachments without any further use, copying<BR>

or forwarding.<BR>

</body>

</html>