Add the directive to include the configuration options to the library
documentation.
Depends-On: I549c8db98bf548dd0a7e8869a57301fa4096f78c
(feature change in oslo.config)
Depends-On: I89e3e4fd41ed4c989c2dd4c9cd1d7b7e806fa15a
(global requirements change to update oslo.config version)
Change-Id: Ibec7071027fc33374a73abc30f8f672380bae6ea
Document the plugins available for executors and notifiers.
Fix the formatting in the aioeventlet executor so the docstring renders
properly.
Change-Id: I7709b65f5aa68fab3822b4de11640309aa07b1d7
Use stevedore.sphinxext to populate a new page listing all available
drivers.
Add docstrings to the driver classes, including references to more
extensive documentation if it is available.
Depends-on: I1a24f9326b4e54174d9dc0ae366315fe29c3ac1b
Depends-on: Ie715f98fe0d3cba8b2f4f6235e7c2b6f79be7ea0
Change-Id: Ief0aa05e6deba0126d63faf13497d0fe0539e08d
Oslo.messaging have an outdated release in the code tree.
but now the release note is published on the mailing.
This change removes it.
Change-Id: I0a3401b7c9bc8230169e75727e45a99e6c3c780f
This guide introduces the basic scenario of zeromq
driver and how to correctly deploy zeromq driver
for OpenStack.
Change-Id: I23eeafc5863b44bfbeb89ce3571a4e79b4b01d01
Closes-Bug: #1382325
Create a new FAQ page and add a few entries related to configuring the
notifier.
Change-Id: Ibfd78b40fe65d20315ad563694dcb7c48641812c
Closes-Bug: #1422774
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
