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
This change warns the library consumer when the process if forked and
we can't be sure that the library work as expected.
This also add some documentation about forking oslo.messaging Transport
object.
Change-Id: I2938421775aa72866adac198d70214856d45e165
Related-bug: #1330199
For greater clarity, that the class is related to logging, PublishErrorsHandler
renamed to LoggingErrorNotificationHandler. Included an alias from the
old name to the new class for backwards-compatibility.
Change-Id: Iae8e26901bab6d5aa7532add31b49a4345b067fe
Closes-Bug: #1287420
Remove intersphinx from the docs build as it triggers network calls that
occasionally fail, and we don't really use intersphinx (links other
sphinx documents out on the internet)
This also removes the requirement for internet access during docs build.
This causes docs jobs to fail because we error out on warnings.
Change-Id: I71e941e2a639641a662a163c682eb86d51de42fb
Related-Bug: #1368910
We're currently including these docs under the RPC server and
notification listener sections causing sphinx to have a minor panic
attack.
WARNING: duplicate object description of oslo.messaging.MessageHandlingServer
Change-Id: I76a4d9a7f55f7b65bcdd2bdb814904dc55bd1068
When log_handler.py was added to oslo.messaging changes weren't made to
publish the documentation. This patch ensures the docs for log_handler
are built.
Change-Id: Ibf60f648ad07875fb4c61427e601b6b268a95f53
Closes-Bug: 1286984
Having the sphinx theme in the same namespace package
as the production code has been causing issues with
devstack installations. The solution settled on was
to rename oslo.sphinx to oslosphinx because oslo.sphinx
is not a "production" library.
See the linked bug report for more background details.
Closes-Bug: #1277168
Change-Id: I220b8901cef36499e91b92719f1e8e5461a95e92
Register a oslo.messaging entry point in the oslo.config.opts namespace
which, when called, returns a list of the configuration options which
may be registered by the library at runtime.
The idea here is that the sample config file generator can query this
and include the returned options in the sample config file of any
applications which use the library.
Some sample code for fetching available options:
import pkg_resources
for ep in pkg_resources.iter_entry_points('oslo.config.opts'):
if ep.name == "oslo.messaging":
list_opts = ep.load()
for g, opts in list_opts():
opts.sort(key=lambda x: x.name)
print "[%s]" % g
for o in opts:
print "%s = %s" % (o.name, o.default)
print
Related-Bug: #1241566
Change-Id: Ic28351258652d2ea38974e2f4d1aa6b1d3dd7192
There's no need to make the fixtures, testtools, etc. libraries a
runtime requirement, so let's move it from the toplevel oslo.messaging
API so you need to explicitly import it.
Change-Id: I9e2f32a898d78489f2d8d9c218c81f35cda14e34
The configuration options registered by oslo.messaging should not be
directly relied upon by users of the library, since those config option
names could change in future.
Add an API which allows API users to override specific configuration
options e.g.
self.messaging_conf = self.useFixture(messaging.ConfFixture(cfg.CONF))
self.messaging_conf.transport_driver = 'fake'
Change-Id: If0d837e1b86e3b04237fde522551cfb81505a543
Nova's cells/rpc_driver.py has some code which allows user of the REST
API to update elements of a cell's transport URL (say, the host name of
the message broker) stored in the database. To achieve this, it has
a parse_transport_url() method which breaks the URL into its constituent
parts and an unparse_transport_url() which re-forms it again after
updating some of its parts.
This is all fine and, since it's fairly specialized, it wouldn't be a
big deal to leave this code in Nova for now ... except the unparse
method looks at CONF.rpc_backend to know what scheme to use in the
returned URL if now backend was specified.
oslo.messaging registers the rpc_backend option, but the ability to
reference any option registered by the library should not be relied upon
by users of the library. Imagine, for instance, if we renamed the option
in future (with backwards compat for old configurations), then this
would mean API breakage.
So, long story short - an API along these lines makes some sense, but
especially since not having it would mean we'd need to add some way to
query the name of the transport driver.
In this commit, we add a simple new TransportURL class:
>>> url = messaging.TransportURL.parse(cfg.CONF, 'foo:///')
>>> str(url), url
('foo:///', <TransportURL transport='foo'>)
>>> url.hosts.append(messaging.TransportHost(hostname='localhost'))
>>> str(url), url
('foo://localhost/', <TransportURL transport='foo', hosts=[<TransportHost hostname='localhost'>]>)
>>> url.transport = None
>>> str(url), url
('kombu://localhost/', <TransportURL transport='kombu', hosts=[<TransportHost hostname='localhost'>]>)
>>> cfg.CONF.set_override('rpc_backend', 'bar')
>>> str(url), url
('bar://localhost/', <TransportURL transport='bar', hosts=[<TransportHost hostname='localhost'>]>)
The TransportURL.parse() method equates to parse_transport_url() and
TransportURL.__str__() equates to unparse_transport().
The transport drivers are also updated to take a TransportURL as a
required argument, which simplifies the handling of transport URLs in
the drivers.
Change-Id: Ic04173476329858e4a2c2d2707e9d4aeb212d127
Oslo's logging code has some useful support for including bits of the
request context in log messages. While this isn't exclusively about the
request context in a dispatching RPC method, it seems useful for
oslo.messaging to support the concept for at least this use case simply
by recording the context in a thread local store before dispatching an
endpoint method and immediately clearing it when the method returns.
Note, we don't need to store weak refs in our store because we will
clear the reference in all cases rather than ever leaving a stale
reference around in the store.
Change-Id: I70ac06ed3a2a891a7a7b388b1823a0f3b08f2dd1
If a remote endpoint raises an exception which the client is not allowed
to (or cannot) deserialize, then RPCClient.call() raises a RemoteError
exception instead.
Make this exception type part of the public API.
Change-Id: I70be0ab7d40af3224d93d6bd0522c1a82f6303c3
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
Use the new oslo.sphinx version of the OpenStack doc
theme instead of copying it into this repo.
blueprint oslo.sphinx
Change-Id: I0bd91f7bb43f97b99051fed65b75fc05d5149cc8
