hacking 3.0.x is too old.
Also, fixtures appears in both requirements and test-requirements.
Because this library is only used in oslo_service.fixtures for testing,
we can remove it from runtime requirements.
Change-Id: Iaf57598a73af62e07e890245dc51c9af6a807bd7
The versions of yappi less than 1.0 have a bug[1] that causes it
to fail to install[2].
This patch makes sure oslo.service uses version 1.0 of yappi that
contains the fix.
[1] https://github.com/sumerc/yappi/commit/ \
778829f6f77928e4292e6a7dd4dfecf501f9a362
[2] http://logs.openstack.org/29/637929/2/check/octavia-v2-dsvm-scenario \
4113e77/controller/logs/dib-build/amphora-x64-haproxy.qcow2_log.txt.gz \
#_2019-02-19_17_23_37_112
Change-Id: I6b72272dcc524ebab30324446fdeaeb742eddc81
Prior versions of oslo.utils have known issues with the EventletEvent
class that we use, so we should avoid them.
Change-Id: Id46634bbbd69caa5294c07d2c0da70856c8cba5b
Related-Bug: 1812922
Related-Bug: 1805706
This patch enables profiling (capturing function call trace like
cProfile [1]) worker processes on the fly while service is running.
User requests the oslo service process to start profiling by writing
"prof()" command to backdoor socket, once the service (like
neutron-server) finishes expected processing (example finishing API
call), user again writes "prof()" command with file name as argument
to dump the function calltrace stats. Stats file (in pstat format
with user provided filename by adding .prof) will be generated in
temp directory.
For example, to profile neutron server process,
1) echo "prof()" | nc localhost 8002
2) Issue neutron command (or run rally scenarios tests)
neutron net-create n1
neutron port-create --name p1 n1
neutron port-delete p1
neutron net-delete n1
3) echo "prof('neutron')" | nc localhost 8002
where 8002 is the port which we set like below in neutron.conf
backdoor_port=8002
We can later print the stats from the trace file like below
stats = pstats.Stats('/tmp/neutron.prof')
stats.print_stats()
The trace file will look like in (for above neutron API calls) [2].
We use Yappi with context set to greenlet [3] to profile greenlets.
We can't use GreenletProfiler [4], which does the same [5]
1) as it is no more maintained
2) Also compiling yappi source inside GreenletProfiler is failing for
python3.
[1] https://docs.python.org/2/library/profile.html
[2] https://gist.github.com/venkataanil/64d5e672bf0206dc151e73fc1058a983
[3] https://bitbucket.org/sumerc/yappi/pull-requests/3
[4] https://pypi.org/project/GreenletProfiler/
[5] https://emptysqua.re/blog/greenletprofiler/
Depends-On: Ibea0cdb732923f1b53d5cb6aeeb4041fb5973494
Change-Id: Id2418093494f1e233a653f6c73bd6894e4a40184
Instead of having a copy-pasted version in this project, let's just
use the original directly. It is added to the public API of
oslo.utils in the dependency.
Depends-On: https://review.openstack.org/614806
Change-Id: If0dfac2505d097c117ef94c99399b1614f1e1f8f
This API is awkward, inefficient, incoherent, and unintuitive. The bug
fix for which it was originally added was abandoned in favour of a
different approach, so it was never used. It appears that no consumers
are currently calling it. It would be best if none started.
Add a deprecation warning to discourage its use and allow us to remove
it altogether at some point in the future.
Change-Id: I9559c7051024019fac957385faced645920b815c
Consumers of loopingcall may wish to exercise their code in test cases
without incurring actual wall clock sleep time in their test runs.
Heretofore, this required digging into the internals of the loopingcall
module and mocking something private (or something hidden by something
private).
This patch exposes a public oslo_service.fixture.SleepFixture for this
purpose. It can be maintained opaquely as internals change without
affecting its consumers.
See [1] for (one example of) the motivation behind this change.
[1] https://review.openstack.org/#/c/615724/
Change-Id: I0089c7778957456db66599abffaaad3a5332243c
A recent requirements change [1] restricted monotonic to <py3.3, meaning
that any subsequent change triggering the requirements-check job will
fail until that's synced. Do that.
In order to make this sane, we need to be sure we're only using
monotonic if it's available. In oslo_service.__init__.py, we're using
the actual library if eventlet is. In periodic_task.py we're using the
actual library if the monotonic() method isn't available in the time
module.
[1] Ib8c1bf08f5fa7463911602b0df19315907c81e04
Change-Id: I3b24a089b780aac2746f48f7d5b538546ccce982
This is preventing any testing of projects with the new eventlet
because it causes a requirements conflict. We need to first remove
the cap in oslo.service in order to move forward with this process.
Change-Id: I1cbd25041981b68a3b2573162cba2f5ea4cb6f85
Takashi Kajinami