Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 913619

Summary: RFE: Provide for live tracing of system operation
Product: Red Hat OpenStack Reporter: Daniel Berrangé <berrange>
Component: openstack-novaAssignee: OSP DFG:Compute <osp-dfg-compute>
Status: CLOSED WONTFIX QA Contact: awaugama
Severity: low Docs Contact:
Priority: low    
Version: 3.0CC: apevec, awaugama, eglynn, jschluet, lruzicka, lyarwood, mbooth, nlevinki, panbalag, sclewis, sgordon, tvignaud
Target Milestone: ---Keywords: FutureFeature, TestOnly, Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: https://blueprints.launchpad.net/nova/+spec/osprofiler-support-in-nova
Whiteboard: upstream_milestone_ocata-3 upstream_definition_approved upstream_status_implemented
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-28 15:18:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1416446    
Bug Blocks: 1427427, 1442136    

Description Daniel Berrangé 2013-02-21 15:58:21 UTC
Description of problem:
When troubleshooting production systems it is desirable to be able to trace all data base queries, web REST calls, messaging service RPC calls, libvirt API calls associated with invocation of a user command or background job. It should be able to collect timing information and stack call paths for each item and provide tools for analysing a series of requests to identify slow points / scalability issues. This bug is track the integration of a system to allow such tracing into OpenStack services.

Comment 2 Russell Bryant 2013-02-26 19:31:26 UTC
Sort of related ... but primarily just around tracking messages between services IIRC

http://www.sandywalsh.com/2012/10/debugging-openstack-with-stacktach-and.html

Comment 3 Solly Ross 2013-06-07 19:04:09 UTC
@danpb: I reviewed your mockup modified my generators, etc such that they no longer use RPC and the nova api, and instead just dump to stderr on SIGUSR1 (similarly to how you did it).  The version object is passed as a parameter, so we don't have to actually import parts of nova from the library itself.  I've placed it in 'oslo.report' (so in the patch below, copy the oslo folder into your own python packages oslo directory (installed by oslo.config).  Hypothetically, it could be used in any of the other projects (with the slight modification to make sure they implement something akin to nova's version.py).  How's that look?

Comment 4 Solly Ross 2013-06-10 17:46:40 UTC
whoops, wrong bug (similar titles)

Comment 5 Alan Pevec 2013-07-12 20:55:53 UTC
Duplicate of RFE bug 978491 ?

Comment 6 Daniel Berrangé 2013-07-15 09:28:35 UTC
(In reply to Alan Pevec from comment #5)
> Duplicate of RFE bug 978491 ?

No, this is not related. I'll have to write up a blueprint for this bug to clarify what I was imagining.

Comment 8 Lee Yarwood 2016-02-11 10:28:33 UTC
Attaching the current osprofiler review for openstack/nova that has missed Mitaka and is heading for Newton at the earliest.

Comment 9 Mike McCune 2016-03-28 23:26:37 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 11 Stephen Gordon 2016-04-20 19:44:26 UTC
Assigned to Lee to review and follow the progress of this specification throughout the Newton cycle.

Comment 15 Stephen Gordon 2016-11-25 18:24:44 UTC
Looks like this was not re-approved in time for Ocata.

Comment 17 Lee Yarwood 2017-01-22 18:21:02 UTC
Moving back to OSP 11, the spec and implementation actually landed in time.

Comment 21 Stephen Gordon 2017-01-25 13:31:38 UTC
Lee can you please provide some instructions for testing this? Then set NEEDINFO on panbalag for qa_ack+.

Comment 43 Lee Yarwood 2018-01-31 15:27:22 UTC
Dropping from OSP 13 as the TripleO work to wire this up during a deployment was not completed. This is now captured in 1416446 as a generic request for 14.