[RFE] Neutron support for OSprofiler

Bug #1335640 reported by Boris Pavlovic on 2014-06-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ryan Moats

Bug Description

To be able to improve OpenStack, and as Neutron we should have cross service/project profiler that will build one trace that goes through all services/projects and measures most important parts.

So I build special for OpenStack library that allows us to do this. More about it:

Changed in neutron:
assignee: nobody → Boris Pavlovic (boris-42)
Changed in neutron:
importance: Undecided → Wishlist
Cedric Brandily (cbrandily) wrote :

This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

Changed in neutron:
assignee: Boris Pavlovic (boris-42) → nobody
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Ryan Moats (rmoats) on 2015-12-08
Changed in neutron:
status: Expired → New
Dina Belova (dbelova) on 2015-12-08
Changed in neutron:
status: New → Confirmed

putting this back as new and marking as RFE so that the drivers team can process it during their next meeting

summary: - Neutron doesn't support OSprofiler
+ RFE: Neutron doesn't support OSprofiler
tags: added: rfe
Changed in neutron:
status: Confirmed → New
assignee: nobody → Ryan Moats (rmoats)
Henry Gessau (gessau) on 2015-12-08
summary: - RFE: Neutron doesn't support OSprofiler
+ [RFE] Neutron support for OSprofiler
Changed in neutron:
status: New → Confirmed

We had [1] filed for Liberty and it stalled and remained in the backlog. That makes me wonder: are we sure that oslo.reports is not going to eat into osprofiler's lunch later on? Should we give priority to oslo.reports integration, which was already approved for Liberty?

Having said that, it's my understanding that adding the initial support to osprofiler would be rather trivial. The biggest effort lies with instrumenting the code etc, which can happen without time boundaries.


[1] https://github.com/openstack/neutron-specs/blob/master/specs/backlog/liberty/adopt-oslo-guru-reports.rst

Ryan Moats (rmoats) wrote :

Re-reading the oslo reports backlog, I'm unconvinced that it provides similar information as osprofiler. Therefore, I'd like to see both go forward at this point (I've signed up to shepherd this rfe if it gets approved)

Ryan: thanks. I'd be good to hear it from the oslo.reports folks, do you know who would be a good contact? I'll touch base with the Nova ptl to see where they stand.

Boris Pavlovic (boris-42) wrote :


OSprofiler & oslo.reports are different tools for different purpose.

OSprofiler allows you to do cross service/project tracing of requests, where oslo.reports will show detailed dump of application on signal.

Take a look at spec for more details: https://review.openstack.org/#/c/103825/

Kevin Benton (kevinbenton) wrote :


oslo.reports is about getting the state of a system at any given time (mem usage, threads, etc). https://github.com/openstack/oslo.reports#osloreports

It doesn't have overlap with osprofiler other than the fact that they both help with debugging.

Folks, thanks for the pointers. I understand the objective of oslo.reports as of now; I was only wondering if the scope remained like that, and for that I wanted to hear from the oslo folks.

One more question I have is: if spec [1] is approved, does it mean that osprofiler is going to be provided as a oslo library, e.g. oslo.profiler?

[1] https://review.openstack.org/#/c/103825/

Or, in other words, if is the project going to show up in list [1]?

[1] http://governance.openstack.org/reference/projects/oslo.html

Boris Pavlovic (boris-42) wrote :


OSprofiler is going to become a part of Oslo, currently it's part of Rally which is not proper place for it.

OSprofiler is not going to change the name because it is already integrated in few OpenStack components and it will be quite painful and useless operation.

We should track [1,2]. When they land, and resolved, Our job is a lot easier. Until then it's probably cautious to wait.

[1] https://review.openstack.org/#/c/254703/
[2] https://review.openstack.org/#/c/103825/

Let's bring this up for discussion.

Changed in neutron:
status: Confirmed → Triaged

I am okay with this one, but I question the timing more than anything else: the integration with neutron is all about details and if they are subject to change we may end up having to revise and revise until we have something functional. I see the Nova integration as a good review platform. Once that merges that should give us a clear green flag to proceed without hurdles.

We talked about this during the drivers meeting [1]. Ryan has volunteered to spearhead the initiative. Let's keep an eye on the pending initiatives in oslo and nova, whilst this is taken care of in Neutron.

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html

tags: added: rfe-approved
removed: rfe
Changed in neutron:
milestone: none → mitaka-2
Dina Belova (dbelova) wrote :

Assigned to myself after some short communication with Ryan - he most probably won't be able to work on this bug. I'll work on this using nova change as a template https://review.openstack.org/#/c/254703/

Changed in neutron:
assignee: Ryan Moats (rmoats) → Dina Belova (dbelova)
Changed in neutron:
milestone: mitaka-2 → mitaka-3
Dina Belova (dbelova) on 2016-01-25
Changed in neutron:
status: Triaged → In Progress
Dina Belova (dbelova) wrote :

will publish first draft today. Sadly had a busy week, meh :( I'll need ~1week to finalise the change - ETA for more or less final variant is Feb8th.

Changed in neutron:
assignee: Dina Belova (dbelova) → Ryan Moats (rmoats)
Changed in neutron:
assignee: Ryan Moats (rmoats) → Dina Belova (dbelova)
Changed in neutron:
assignee: Dina Belova (dbelova) → Salvatore Orlando (salvatore-orlando)
Changed in neutron:
milestone: mitaka-3 → mitaka-rc1
Changed in neutron:
milestone: mitaka-rc1 → newton-1
Changed in neutron:
assignee: Salvatore Orlando (salvatore-orlando) → Dina Belova (dbelova)
Changed in neutron:
assignee: Dina Belova (dbelova) → Ryan Moats (rmoats)
Changed in neutron:
assignee: Ryan Moats (rmoats) → Armando Migliaccio (armando-migliaccio)
Changed in neutron:
assignee: Armando Migliaccio (armando-migliaccio) → Ryan Moats (rmoats)

Reviewed: https://review.openstack.org/273951
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9a43f58f4df85adc2029c33ba000ca17b746a6eb
Submitter: Jenkins
Branch: master

commit 9a43f58f4df85adc2029c33ba000ca17b746a6eb
Author: Dina Belova <email address hidden>
Date: Fri Jan 29 11:54:14 2016 +0300

    Add OSprofiler support

    * Add osprofiler wsgi middleware. This middleware is used for 2 things:
      1) It checks that person who wants to trace is trusted and knows
         secret HMAC key.
      2) It starts tracing in case of proper trace headers
         and adds first wsgi trace point, with info about HTTP request

    * Add initialization of osprofiler at start of service
      Currently that includes oslo.messaging notifer instance creation
      to send Ceilometer backend notifications.

    Neutron client change: Ic11796889075b2a0e589b70398fc4d4ed6f3ef7c

    Co-authored-by: Ryan Moats <email address hidden>
    Depends-On: I5102eb46a7a377eca31375a0d64951ba1fdd035d
    Closes-Bug: #1335640
    DocImpact Add devref and operator documentation on how to use this
    Change-Id: I7fa2ad57dc5763ce72cba6945ebcadef2188e8bd

Changed in neutron:
status: In Progress → Fix Released

This issue was fixed in the openstack/neutron development milestone.

This issue was fixed in the openstack/python-neutronclient 6.2.0 release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers