Open Stack

On 01.03.2016 07:17, Kekane, Abhishek wrote:
> 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.

I believe the former option should work good as well. By the way, any
plans to track requests down to the root wrappers' shell commands? There
is also interesting R&D related to the topic directly [0], see "4.
Logging and coordination". Would be nice to reach those people and ask
for code snippets or cooperation as well...

[0] https://kabru.eecs.umich.edu/papers/publications/2013/socc2013_ju.pdf

> 
> [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.
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando