When logging a message, any secrets and passwords should be masked. This
uses oslo_utils.strutils to mask any passwords that are to be logged.
Change-Id: I263d44c0f2e900c5f6e210cbd7ec56e48d0d5bb2
Closes-Bug: #1487038
Add hacking rule borrowed from keystone to make sure
we don't regress and fix all the issues found by the
hacking check.
Change-Id: I41635fdd83c3e04d04f9849a72c49ccb5ac42875
- added config options to set debug level
- added config options to show proceed messages per second on rpc-server
- added config options to select executor for rpc-server
- added config options to select call or cast mesages for rpc-client
Usage section updated
Change-Id: Ieadbc600f556ca5eb43b05abec69315b46023662
Pushing upstream a patch we used for debugging several rabbit
issues in an old fork of oslo.messaging. Use the new
LOG.trace() functionality from oslo.log 1.8.4
Co-Authored-by: Bogdan Dobrelya <bdobrelya@mirantis.com>
Co-Authored-by: Alexei Kornienko <akornienko@mirantis.com>
Co-Authored-by: Oleksii Zamiatin <ozamiatin@mirantis.com>
Change-Id: I0033bba47002f9685479bbd55b29746a06563a51
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
Message will not be handle after acknowledge failure, but it will store
in cache to prohibit handle duplicate message by skipping it.
So a message can be missed if client receive a duplicate message.
Fix this problem by store the message info in cache after a successfuly
message acknowledgment.
Change-Id: I907a58199eeadac22c31490111ec51ee6dd874d5
listen_for_notifications() accepts `pool` argument in driver classes, so
we should add this argument to the base abstract class as well.
Change-Id: Ic52924bb66c8a89cdc90102b1171427806e9a823
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
Document the plugins available for executors and notifiers.
Fix the formatting in the aioeventlet executor so the docstring renders
properly.
Change-Id: I7709b65f5aa68fab3822b4de11640309aa07b1d7
This change introduces to possibility for the consumer application
to change the default oslo.messaging config options.
Same API interface as oslo.db have been taken.
The first option is executor_thread_pool_size.
This option was called rpc_thread_pool_size, but because it's used by
notification and rpc 'executor_thread_pool_size' looks a better name.
Changing executor_thread_pool_size default will be useful for ceilometer
the default of 64 is really to small to consume many notifications at
once for batching them. When is clearly sufficient for rpc stuffs.
Change-Id: Iea0d7a72e38d27c600403c815258aa5eee0d0c8c
quote method has a safe parameter which is set to '/' so when
the end user has a / in the rabbit_password then we end up leaving
that in the url which ends up looking like:
amqp://stackrabbit:pass/word@10.0.0.9:5672//
Which is clearly invalid, so we should set safe parameter to '' which
allows the url to be constructed properly (see transport.py
TransportURL.__str__ method works this work)
Closes-Bug: #1474933
Change-Id: I14fb54440d0925f3676e18d13182ed0fa9c34ca2
Sometimes the gate fails because a test take a bit more time than
expected, this change adjusts this.
Closes-bug: #1475502
Change-Id: I7396c9de82aab18e84c0e08cc1f6f0903884130a
It appears the the callback variable that was being called on
future done was not the right one, due to the lambda capture
mechanism referring to a lazy variable which would potentially
be a different callback by the time the future would finish so
make sure we capture the right one and ensure the future has access
to it.
This adds a helper method that submission will go through
to ensure that the callback variable is correctly captured
in the created lambda and also ensures that the incomplete futures
list is cleaned up (when the future is done).
The notification listener tests use now eventlet to show up this
issue that doesn't occur with blocking executor.
Closes-bug: #1474943
Closes-bug: #1475307
Change-Id: I23e393d504662532572b5b344b87387be6d7bcb1
Blueprint remove-namespace-packages
Depends-on: I2eeef93ee2e61a721c69f62add819f93f62f077d
for openstack/ceilometer
Depends-on: I26390dd908769be5f1a5b70be22d3b98e3a45563
for openstack/ceilometermiddleware
Depends-on: Ifa8baab33cdb3e606cf175a8c29c3a4ef6c44480
for openstack/glance
Depends-on: I029c3260051aa48cfaae428c096c1ac7b43b2bd2
for openstack/ceilometermiddleware
Change-Id: I8c5595bbafa82db33f62fa47d214f5cb756a2639
