The serializer tests occasionally fail since the order of a dict() is
not guaranteed. Explicitly compute the serializer instead of
pre-computing it.
Change-Id: I74f8fa227e6508491b5982fe7e2841683724540c
Using blocking executor is not recommended for application. But it looks
like some use it just because it's the default and are not aware their
should change it despite of documentation and logging message.
Choosing the application threading model is an important step
of an application.
This change deprecates it, in the future we will just make executor
mandatory. This will ensure that application make a choice.
Also this will reduce headache of oslo.messaging developers to
make the driver code working in a sync and async.
And to finish test coverage of blocking executor is 0%...
This rework some tests to remove logging.captureWarnings() that can
catch unwanted warning of other tests. Tests mocks warning instead.
Related-bug: #694728
Change-Id: Ic67164d12e7a9bed76d6e64ca2ced12e3984ff5f
The get_rpc_transport wraps get_transport to unify the API in
anticipation of comprehensive separation of RPC and Notification
messaging backends.
Related-Bug: 1680192
Change-Id: Ic6af07b98ff43806c2af38a3ba129991f1e0ec86
OpenStack projects should be using mock rather than mox.
oslo.messaging was using mox's stubs via oslotest rather than
mock.patch.object. The code is converted to use mock.patch.object
via fixtures.MockPatchObject.
Change-Id: I19490b4e8211c35b237ebfd38bf2f8b8b44cbf61
dict doesn't seem always keep order on Python. we have two separate part
to prepare test data[1], calling 'for k, v in self.args.items()' and
'for arg in self.args:' may get data in different order.
This commit makes we collect test data in same order.
Change-Id: I49f0d1b9aed110ad1e59140fd70760682e944d74
Related-Bug: #1677151
debtcollector's decorator updated_kwarg_default_value is used to indicate
default value will be changed in future version. We introduced parameter
access_policy and add itfor constructor method of RPCDispatcher in
d3a8f280ebd6fd12865fd20c4d772774e39aefa2. Other services usually call
get_rpc_server method instead of calling constructor method of
RPCDispatcher. get_rpc_server method constructs RPCDispatcher instance
in [1], then FutureWarning will be generated even we set parameter
access_policy explicitly. Need move the decorator updated_kwarg_default_value
to method get_rec_server to avoid the case.
Closes-Bug: #1661572
[1] f1efaf1b6e/oslo_messaging/rpc/server.py (L200).
Change-Id: I3214045856d0bbd05a0000eeafb769e4697cd34c
The mock module has been added to Python 3.3 as unittest.mock.
The third party mock module doesn't seem to be maintained anymore.
This is follow up of 72c501454ea33b603918de35565a66dda8abd66a and
add hacking rule to avoid regression issue.
oslotest prepares mock for six in oslotest/__init__.py as follow:
six.add_move(six.MovedModule('mock', 'mock', 'unittest.mock')) and
oslo_messaging/tests/__init__.py imports oslotest before importing
test submodules to setup six.moves for mock, then "from six.moves
import mock" works well.
Note: unittest.mock also detects wrong usage of method
assert_called_once_with.
Change-Id: I3d09733789cfa2550cf47c24f2553357d36bcc0d
Implements access_policy for dispatcher to restrict endpoint methods.
Implements the following access policies:
* LegacyRPCAccessPolicy
* DefaultRPCAccessPolicy
* ExplicitRPCAccessPolicy
* Implement decorator @rpc.expose for use with the
ExplicitRPCAccessPolicy
* Modify get_rpc_server to allow optional access_policy argument
* Set default access_policy to LegacyRPCAccessPolicy (Nova exposes
_associate_floating_ip in tempest tests). Added debtcollector
notification.
* Add test cases for access_policy=None
* Clarify documentation
Change-Id: I42239e6c8a8be158ddf5c3b1773463b7dc93e881
Closes-Bug: 1194279
Closes-Bug: 1555845
Many assertEqual sentences don't follow assertEqual(expected, actual),
These misplaces have 2 impacts:
1, giving confusing messages when some tests failed.
2, mislead other developers, new test modules may follow these wrong pattern.
This patch fix all of them.
Change-Id: Icc6e404dd02fe47b76c7366d31d91c8d8e464f54
Closes-Bug: #1604213
This patch removes log_failure argument from the function
serialize_remote_exception and from driver implementations
using it (because it is never used and always defaults to True)
and prevents error logging in this function (because these errors
are already logged by servers while processing incoming messages).
Change-Id: Ic01bb11d6c4f018a17f3219cdbd07ef4d30fa434
Closes-Bug: 1580352
This patch fixes the bug in the RPCClient class when a client's
version_cap is set, but target.version is unset. The code does not
check this case, which results in unhandled exceptions.
Change-Id: I623c14b74b9101bb4ab199dff6609fab44388c4a
Closes-Bug: 1574615
Current Listener interface has poll() method which return messages
To use it we need have poller thread which is located in MessageHandlerServer
But my investigations of existing driver's code shows that some implemetations have
its own thread inside for processing connection event loop. This event loop received
messages and store in queue object. And then our poller's thread reads this queue
This situation can be improved. we can remove poller's thread, remove queue object
and just call on_message server's callback from connection eventloop thread
This path provide posibility to do this for one of drivers and leave as is other drivers
Change-Id: I3e3d4369d8fdadcecf079d10af58b1e4f5616047
Dispatcher should be responsible for routing message to the
callback method of endpoint object and returning result back to the
server only. But now it is also responsible for sending reply,
ack/reque messages etc.
Also this patch makes small improvements:
1) Notification dispatcher now requeue message if endpoint raises exception
2) unstable behaviour of test_mask_passwords test is fixed
Change-Id: I5f23e23644e90919cb67f81fc306ee85c5e09974
Now we have situation when openstack projects like Mistral needs
extra oslo.messaging functionality.
But it is too complicated now to to implement something new and
integrate it with current code because there is a little bit mess.
1) Executor should be responsible for how to run jobs
(but now also has code with server logic)
2) Dispatcher should be responsible for routing message to the
target endpoint for processing (but it also has serialisation, sending replies,
executing some executor's callbacks etc)
3) Server should do all server specific logic, we need to have different
implementation of servers for RPC and notification, not different implementations
of dispatchers
This patch fixes 1-st point
Change-Id: Ib6408f408889bb7b7056722be636a5547b1a780d
-- "cls.scenarios = filter(f, cls.scenarios)"
It's better to set a list to cls.scenarios but filter()/map() returns
an iterator on Python 3. This patch we replaced the filter()/map() with
a list comprehension in test_server.py.
Change-Id: I16640e564d41c6a1c29e229049467ae788bb1437
related to Id3af696193af2ccf5e5f3a1ae1d22f4f80860606. we need to make
override_pool_size accessible for external use.
Change-Id: I686c8c341f117dbc0b02443306395d5fd011c2f1
Somehow we sneaked in a change to ignore pep8 on tests/ directory.
Let's cleanup the code and re-enable pep8
Closes-Bug: #1540981
Change-Id: Ic002134a0d0c498991b062466e00068d6ac1f1ab
Fixed pep8 errors:
* E127 continuation line over-indented for visual indent
* E226 missing whitespace around arithmetic operator
* E231 missing whitespace after ','
* E241 multiple spaces after ','
* E261 at least two spaces before inline comment
* E301 expected 1 blank line, found 0
* E302 expected 2 blank lines, found 1
* E303 too many blank lines (2)
* E501 line too long (80 > 79 characters)
Fixed pep8 warnings:
* W292 no newline at end of file
* W391 blank line at end of file
Change-Id: I1736f8a42c3a335a17a0b9b6e64782487ed3a495
Each config option has limitation for type and value. If we use
method CONF.set_override without parameter enforce_type=True, we
may pass wrong type to config option.
This commit makes sure calling method CONF.set_override with
enforce_type=True.
Change-Id: I1430c93777d6e5d98086a8700663ab9f58c1e5ab
Closes-Bug: #1517839
The usage of assertEqual(True/False, ***) should be changed
to a meaningful format of assertTrue/False(***).
Change-Id: Idda812a34be8aa53654d6791eac47028339d3cb7
Closes-Bug:#1512207
1. Use translation marker functions, their argument must just be a string
2. Any message with more than one variable should use named
interpolation instead of positional to allow translators
to move the variables around in the string to account for
differences in grammar and writing direction.
3. String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
For more details, please refert to oslo.i18n guideline [1]
Note: this commit doesn't touch test code.
[1] http://docs.openstack.org/developer/oslo.i18n/guidelines.html
Change-Id: I5f013d65b20396bbe0e5a2cceaed2a33fad1af23
Gnocchi performs better if measurements are write in batch
When Ceilometer is used with Gnocchi, this is not possible.
This change introduce a new notification listener that allows that.
On the driver side, a default batch implementation is provided.
It's just call the legacy poll method many times.
Driver can override it to provide a better implementation.
For example, kafka handles batch natively and take benefit of this.
Change-Id: I16184da24b8661aff7f4fba6196ecf33165f1a77
This change formalises locking in MessageHandlingServer, which closes
several bugs:
* It adds locking for internal state when using the blocking executor,
which closes a number of races.
* It does not hold a lock while executing server functions,
which removes a potential cause of deadlock if the server does its
own locking.
* It fixes a regression introduced in change
gI3cfbe1bf02d451e379b1dcc23dacb0139c03be76. If multiple threads
called wait() simultaneously, only 1 of them would wait and the
others would return immediately, despite message handling not having
completed. With this change only 1 will call the underlying wait,
but all will wait on its completion.
Additionally, it introduces some new functionality:
* It allows the user to make calls in any order and it will ensure,
with locking, that these will be reordered appropriately.
* The caller can pass a `timeout` argument to any server method, which
will cause it to raise an exception if it waits too long.
* The caller can pass a `log_after` argument to any server method,
which will cause it to raise a log message if it waits too long. It
can also be used to disable logging when waiting is intentional.
We remove DummyCondition as it no longer has any users.
This change was originally committed as change
I9d516b208446963dcd80b75e2d5a2cecb1187efa, but was reverted as it
caused a hang in a Nova test. This was caused by the locking behaviour
for handling restarting a previously stopped server. The original
patch caused the state to 'wrap' immediately after the user called
wait(). This caused a hang in tests which redundantly called stop()
and wait() multiple times. This new patch only wraps when the user
calls start() again. Callers who do not restart a server will
therefore not be affected by the wrapping behaviour. Callers who do
restart a server will be no worse than before. We add a deprecation
warning on restart, as this operation is inherently racy with this api
and there is a simple, safe alternative.
This new version has been successfully tested against the unit and
functional tests of nova, cinder, glance, and ceilometer.
Change-Id: Ic79f87e7b069c1f62d6121486fd6cafd732fdde7
This reverts commit d700c382791b6352bb80a0dc455589085881669f.
This commit is causing a timeout/lock wait condition when using the in
memory rpc bus. It exposed in the Nova unit / functional tests which use
this extensively.
Change-Id: I9610a5533383955f926dbbb78ab679f45cd7bcdb
Closes-Bug: #1514876
This change formalises locking in MessageHandlingServer. It allows the
user to make calls in any order and it will ensure, with locking, that
these will be reordered appropriately. It also adds locking for
internal state when using the blocking executor, which closes a number
of races.
It fixes a regression introduced in change
gI3cfbe1bf02d451e379b1dcc23dacb0139c03be76. If multiple threads called
wait() simultaneously, only 1 of them would wait and the others would
return immediately, despite message handling not having completed.
With this change only 1 will call the underlying wait, but all will
wait on its completion.
We add a common logging mechanism when waiting too long. Specifically,
we now log a single message when waiting on any lock for longer than
30 seconds.
We remove DummyCondition as it no longer has any users.
Change-Id: I9d516b208446963dcd80b75e2d5a2cecb1187efa
This fixes a race due to the quirkiness of the blocking executor. The
blocking executor does not create a separate thread, but is instead
explicitly executed in the calling thread. Other threads will,
however, continue to interact with it.
In the non-blocking case, the executor will have done certain
initialisation in start() before starting a worker thread and
returning control to the caller. That is, the caller can be sure that
this initialisation has occurred when control is returned. However, in
the blocking case, control is never returned. We currently work round
this by setting self._running to True before executing executor.start,
and by not doing any locking whatsoever in MessageHandlingServer.
However, this current means there is a race whereby executor.stop()
can run before executor.start(). This is fragile and extremely
difficult to reason about robustly, if not currently broken.
The solution is to split the initialisation from the execution in the
blocking case. executor.start() is no longer a blocking operation for
the blocking executor. As for the non-blocking case, executor.start()
returns as soon as initialisation is complete, indicating that it is
safe to subsequently call stop(). Actual execution is done explicitly
via the new execute() method, which blocks.
In doing this, we also make FakeBlockingThread a more complete
implementation of threading.Thread. This fixes a related issue in
that, previously, calling server.wait() on a blocking executor from
another thread would not wait for the completion of the executor. This
has a knock-on effect in test_server's ServerSetupMixin. This mixin
created an endpoint with a stop method which called server.stop().
However, as this is executed by the executor, and also joins the
executor thread, which is now blocking, this results in a deadlock. I
am satisfied that, in general, this is not a sane thing to do.
However, it is useful for these tests. We fix the tests by making the
stop method non-blocking, and do the actual stop and wait calls from
the main thread.
Change-Id: I0d332f74c06c22b44179319432153e15b69f2f45
test_server_wait_method was calling server.wait without having
previously called server.start and server.stop. This happened to work
because it also injected server._executor_obj. This is problematic,
though, as it assumes internal details of the server and does not
represent the calling contract of server.wait, which is that it must
follow server.stop (which must itself also follow server.start).
This change makes the necessary changes to call server.wait in the
correct sequence.
Change-Id: I205683ac6e0f2d64606bb06d08d3d1419f7645f4
MessageHandlingServer has both MessageHandlingServer.executor, which
is the name of an executor type, and MessageHandlingServer._executor,
which is an instance of that type. Ideally we would rename
MessageHandlingServer.executor, but as this is referenced from outside
the class we change _executor instead to _executor_obj.
Change-Id: Id69ba7a0729cc66d266327dac2fd4eab50f2814c
Instead of having to spin in the wait method, just use
a condition and block until stopping has actually happened,
when stop happens, it will use the notify_all method to let
any blockers release.
Closes-Bug: #1505730
Change-Id: I3cfbe1bf02d451e379b1dcc23dacb0139c03be76
abandonning -> abandoning
for output of oslo_messaging/_drivers/impl_rabbit.py
Plus some small fix for source comments/config help.
Change-Id: Ia4bd1465cbe8beef8e109d20e5ddbec12d6d8e8f
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
We want to ensure start have really finish before the caller
use stop to not go into weird driver state.
Inteads of raise RuntimeError or just printing warning, we
now use a lock to protect the state change of the server.
So stop will just wait that the server finish to start before
stopping.
This also removes the need to start/stop the server from the
same thread just to fix the state consistency of drivers when
thread or eventlet executor is used.
Change-Id: Ia7346f6cc0bbe8631a2e3318c7031b34ab1ec510
Changes introduced in:
I0fc1717e3118bc1cd7b9cd0ccc072251cfb2c038
are causing Neutron to fail as summarized by Doug in:
http://markmail.org/message/2xlclp7gqnqpkted
So we should log warnings instead and make sure we
find which projects are affected (using logstash) and
fix them. Once we do that, then we can switch this
back to raise RuntimeError(s)
Change-Id: I9dce272246b89f3ec63aefcf11d385fd2d21da6e
It's documented, the application consumer must not use wait before stop.
but this is not enforced, so enforce it
Also the code assume start/stop/wait are called from the same thread,
but this is not enforced, so enforce it.
A common broken usage is:
server = oslo.messaging.get_rpc_server(..., executor='eventlet')
t = threading.Thread(target=server.start)
t.daemon = True
t.start()
...foobar code...
server.stop()
server.wait()
With monkey patching, start() will do a context switch and then stop()
is called but start is unfinished, that can cause unexpected behavior.
This patch fixes these issues by making all of this explicit.
Closes-bug: #1465850
Closes-bug: #1466001
Change-Id: I0fc1717e3118bc1cd7b9cd0ccc072251cfb2c038
The context manager in the executor fit only for the blocking executor.
Even the dispatcher needs to run code before and after the application
callback, eventlet and future executors have to run the pre/post code
into the main thread and can run the callback into an other thread,
and that force them to run __enter__ and __exit__ manually and deal
the exception path.
This change adds a helper object instead of the context manager.
It is designed to be explicit on what must be executed
before and after the callback and what can be done in a thread or not.
All the executor code is now in the impl_pooledexecutor.py
and use the futures "PoolExecutor" API.
This use futurist to provide a eventlet and aioeventlet futures friendly
object.
Change-Id: I8cd7640f36beeda47560e3c82671bad3530e38d1
Raise an exception if a caller passes a something for the
version that cannot be parsed as a version.
Change-Id: I167849b1bc6c4d946de42c6459b3577a361e9606
Related-Bug: #1467087
The mock module has been added to Python 3.3 as unittest.mock.
The third party mock module doesn't seem to be maintained anymore: the
last commit was in April 2013.
unittest.mock is more recent, has less bugs and is compatible with
Python 3.4. There are bugs on Python 3 in the third party mock module,
examples:
* https://code.google.com/p/mock/issues/detail?id=225
* https://code.google.com/p/mock/issues/detail?id=234
Oslo Messaging hits these issues when running tests on Python 3.4.
Import oslotest to setup six.moves for mock.
Change-Id: Ic160101695cea67eb9bbbfcaddb8d3dac64e6804
In order for projects to use the namespace property of Targets
in a backwards compatible way (To support rolling upgrades),
a Target may now belong to more than a single namespace (i.e.
'namespace1' and None). This way, if the server is upgraded first,
the version that introduces namespaces to a project will place
the server RPC methods in ['some_namespace', None]. Pre-upgrade
agents will send messages in the null namespace while post-upgrade
agents will send messages in 'some_namespace', and both will be
accepted.
Change-Id: I713fe9228111c36aa3f7fb95cbd59c99100e8c96
Closes-Bug: #1430984
Move the public API out of oslo.messaging to oslo_messaging. Retain
the ability to import from the old namespace package for backwards
compatibility for this release cycle.
bp/drop-namespace-packages
Co-authored-by: Mehdi Abaakouk <mehdi.abaakouk@enovance.com>
Change-Id: Ia562010c152a214f1c0fed767c82022c7c2c52e7
