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
This patch exposes some private symbols used by the tests in nova and
heat.
Change-Id: Ide40b293c9b9c76aae094950720cead4179ea883
Partial-Bug: #1412812
Partial-Bug: #1412841
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
The concurrent.futures module is one of the ways
that async activities can be done in the future,
so we should try to work on getting to that future
by using more futures. To enable this (as well as
to enable getting off eventlet), add a thread pool
based executor which will process incoming messages
using the pool.
Also begins adding according docs as well for the
different types of executors that are available.
Change-Id: I1482fd70abbf69f4e2994597c5e95d91fecb815e
This change warns the user that it does have monkeypatched the
oslo.messaging library correclty.
Change-Id: Ice80ffc6cbc39919eac4bc0809992daea51b5922
Closes-bug: #1288878
It's up to the driver to set a suitable timeout for polling the broker,
this one can be different that the one requested by the driver
caller as long as the caller timeout is respected.
This change also adds a new driver listener API, to be able
to stop it cleanly, specially in case of timeout=None.
Closes bug: #1400268
Closes bug: #1399257
Change-Id: I674c0def1efb420c293897d49683593a0b10e291
This change allows to stop the eventlet executor without
using eventlet.kill.
And also, the kombu docs actually recommend that drain_events
by default have a 1 timeout.
Co-Authored-by: Joshua Harlow <harlowja@yahoo-inc.com>
Change-Id: I3a3919e38d08267439843a127346300fd2131540
We can now set the pool name of a notification listener
to create multiple groups/pools of listeners consuming notifications
and that each group/pool only receives one copy of each notification.
The AMQP implementation of that is to set queue_name with the pool name.
Implements blueprint notification-listener-pools
Closes-bug: #1356226
Change-Id: I8dc0549f5550f684a261c78c58737b798fcdd656
The test spawns a greenthread and expects it to complete after
eventlet.sleep(0) call. The problem is that if there are other
greenthreads currently running, sleep(0) may switch to unexpected
thread, which may result in test thread not being invoked at all.
Instead of assuming no other green threads are running at the moment
of test execution, explicitly wait() for the test thread.
Change-Id: Id45307860733658638b74ed3a713493df8c1080d
Closes-Bug: #1282706
The notification listener doesn't have anything to send to the notifier
and the notifier doesn't attend to receive something.
So this patch remove the message reply when the listener is a
notification
listener.
Partial implements blueprint notification-subscriber-server
Change-Id: Ic989947ba3b6894cde788422842fca19159ea261
Follow oslo.config style guide for help strings better to create
consistent help strings:
* Capitalize first word of each help string
* Finish help strings with "."
Change-Id: Ia08fa09593661e6e5b834d98bbd92689c2674075
Catch expected exceptions in a way that supports subclasses also being
seen as "expected."
Log a little more detail about unexpected exceptions in the ExecutorBase
so it is easier to add them to the list of expected exceptions.
Change-Id: I1bdd628eba717308f0afe1a889efd8711bad6296
Closes-bug: #1276163
__metaclass__ cannot be used in python3.six be used in general
for python 3 compatibility.
Porting Change-Id I9fc7a59df3af29b4cc1287c40fa4e883d994a961
from oslo-incubator
Change-Id: Icdacdcf5556b6d3b8450d1350c6f62b4f5a9690b
There are a number of situations in which we log a message if an
exception occurs during the handling of a message:
1) Something goes wrong pulling the message from the queue and
de-serializing it - here we print "Failed to process message"
2) An RPC endpoint method raises an expected exception - here we
print an 'Expected exception during message handling' debug
message
3) An RPC endpoint method raises any other exception - here we
should print an 'Exception during message handling' error message
However, in the latter case, we are currently printing out the 'Failed
to process' error message.
Change-Id: I4f7042b8ec978aaff8f4e20e62ba1ac765fe6ba5
A rather embarassing and obvious bug - we're currently not allowing
endpoint methods to send replies of None, '', False, [], {}, etc.
Change-Id: Ifc5ff8f308f526197559a4df7bed244cff6ed3c1
Review I4e7b19dc730342091fd70a717065741d56da4555 gives a lot of the
background here, but the idea is that some exceptions raised by an RPC
endpoint method do not indicate any sort of failure and should not be
logged by the server as an error.
The classic example of this is conductor's instance_get() method raising
InstanceNotFound. This is perfectly normal and should not be considered
an error.
The new API is a decorator which you can use with RPC endpoints methods
to indicate which exceptions are expected:
@messaging.expected_exceptions(InstanceNotFound)
def instance_get(self, context, instance_id):
...
but we also need to expose the ExpectedException type itself so that
direct "local" users of the endpoint class know what type will be used
to wrap expected exceptions. For example, Nova has an ExceptionHelper
class which unwraps the original exception from an ExpectedException and
re-raises it.
I've changed from client_exceptions() and ClientException to make it
more clear it's intent. I felt that the "client" naming gave the
impression it was intended for use on the client side.
Change-Id: Ieec4600bd6b70cf31ac7925a98a517b84acada4d
We appear to not have a use for this. I had originally thought we might
use this to ack messages one they've been processed and replied to, but
we actually have always acked messages as soon as they have been
deserialized and queued for dispatching.
Change-Id: I8e1fd565814f3b5e3ba0f1bc77e62ed52ff08661
Doug Hellmann