[RFE] Neutron support for OSprofiler

[Boris Pavlovic]

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:
https://github.com/stackforge/osprofiler

[Cedric Brandily (cbrandily)]

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.

[Launchpad Janitor (janitor)]

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

[Ryan Moats (rmoats)]

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

[Armando Migliaccio (armando-migliaccio)]

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.

Thoughts?

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

[Ryan Moats (rmoats)]

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)

[Armando Migliaccio (armando-migliaccio)]

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)]

Armando,

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)]

@Armando

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.

[Armando Migliaccio (armando-migliaccio)]

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/

[Armando Migliaccio (armando-migliaccio)]

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)]

Armando,

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.

[Armando Migliaccio (armando-migliaccio)]

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/

[Armando Migliaccio (armando-migliaccio)]

Let's bring this up for discussion.

[Armando Migliaccio (armando-migliaccio)]

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.

[Armando Migliaccio (armando-migliaccio)]

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

[Dina Belova (dbelova)]

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/

[Armando Migliaccio (armando-migliaccio)]

status update: http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-01-28-22.20.log.txt

[Dina Belova (dbelova)]

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.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/273951

[OpenStack Infra (hudson-openstack)]

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
    APIImpact
    Change-Id: I7fa2ad57dc5763ce72cba6945ebcadef2188e8bd

[Doug Hellmann (doug-hellmann)]

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

[OpenStack Infra (hudson-openstack)]

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