Open Stack

Hi,

Added openstack-operators in cc so that they can share there views as well.

Abhishek

________________________________________
From: Bogdan Dobrelya [bdobrelia at mirantis.com]
Sent: Tuesday, March 01, 2016 3:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][log] Ideas to log request-ids in cross-projects

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

__________________________________________________________________________
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

______________________________________________________________________
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.