The main issue with eventlet.green.zmq is that libzmq as a C-library
is completely monkey-patch unfriendly. So any blocking call inside
the native library makes calling process stuck. We can't avoid this
actually in an absolutely normal situation when a client appears
earlier than listener we have all client process get stuck until listener
raised. If the listener for example is also blocked awaiting for some
other service to appear we have a chain of locks which may occasionally
result in a dead-lock. The other situation with Notifier is quite similar.
For that reason zmq-broker was restored, but now it serves as an outgoing
queue on a client side. Servers remained the same dynamically port-binded.
Now all clients can still use green-zmq, but presence of the broker-queue
on a host guarantees that green threads will never blocked in a client
because all messages will wait their listeners inside the broker queue.
The broker process's modules are not monkey-patched, they make use of native
threading and native zmq.
Possibility to run without broker also remains. The option zmq_use_broker
introduced for that reason.
Closes-Bug: #1497315
Change-Id: I786b100fd6ee1cf4b99139db0ca044d358d36345
Our class hierarchy hides classes and modules that so its hard
for folks to write a custom Notification driver. We should
make these public and document them
Closes-Bug: #1426046
Change-Id: Ifb96c2ae9868426cac2700bf4917c27c02c90b15
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 replaces the old outdated matchmakers and replace it into the
new ones.
Call/Cast test_specific_server() functional tests passes now.
Change-Id: I8635396110d30d26812f39b242fbbabd1a0feaaa
This removes the 2.6 classifier so that support for 2.6
is not noted (when building packages, on pypi...) as happening
anymore for oslo.messaging (since check/gating support for
it has been turned off).
Depends-On: I4013bf38a197c9a9d82b3956ddbd25450d913df9
Change-Id: Ic4150332fff0724e5178e14f91ac54d5a80d408b
The new executor supports trollius coroutines, explicit asynchronous
programming, in addition to eventlet greenthreads, implicit asynchronous
programming.
The new AsyncioEventletExecutor class is based on the EventletExecutor
class and so it is compatible with it. The aioeventlet executor can be
used to replace the eventlet executor, but it requires an aioeventlet
event loop running in the thread running the executor (usually the main
thread). See AsyncioEventletExecutor docstring for an example how to
setup such event loop.
The aioeventlet module implements the asyncio API (PEP 3156) on top of
eventlet, see aioeventlet documentation:
http://aioeventlet.readthedocs.org/
The change adds an unit test with an endpoint implemented as a trollius
coroutine.
The executor is not supported on Python 3 yet because of eventlet issues
with monkey patching.
Implements: blueprint greenio-executor
Change-Id: I7a78ed998719a703077232726f66d882463b1297
It seems like this was forgotten about; add it so
that people can more easily use this executor and
use it.
Change-Id: I4590bb7f224569d73683c640dd46bde48f8003c3
This properly deploys the oslo.messaging package may resolve
sphinx build errors for projects which have not yet
upgraded to oslo_messaging.
Change-Id: I4db750fb2356ebf44a8fccf7c422b474fefec0ee
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
This change ensures that the amqp1 will be present into the
configfile even the required python module are not present and
also put them into the correct section, [oslo_messaging_amqp1].
Change-Id: I1005405d7ed51090495688eadbe400dbff7c3cc9
The key driver interfaces are implemented in the ProtonDriver class in
driver.py. The logic for interfacing with Pyngus in order to
send/receive messages, manage AMQP connections and links, and handle
protocol events is in controller.py. eventloop.py is a fairly generic
socket connection and I/O processor which runs in its own thread.
controller.py uses the eventloop.py thread to schedule subscription
and message send requests from the driver, as well as handle all
protocol event callbacks coming from Pyngus.
Included in this patch are a set of functional tests that can be run
under tox (tox -eamqp1). These tests fully exercise the new driver,
from the driver API down to the 'wire' - nothing in the driver is
mocked out. The functional tests implement a simple loopback test
broker, which allows the driver to send and receive messages via the
local network. All RPC call patterns, RPC timeouts, and even broker
failover are verified by the included functional tests.
This driver uses the Pyngus module, which is a pure-python client API
built on the Proton AMQP 1.0 protocol engine library from the Apache
Qpid project. Pyngus is available via pypi.python.org.
This driver introduces a dependency on the Proton AMQP 1.0 protocol
library, which is a platform-dependent library that must be installed
in order to use this driver and run the functional tests.
Change-Id: I871703e4cdc04cee3e6c214e911c9df464ede2ed
Implements: blueprint amqp10-driver-implementation
To start translation, we need to initially import the
translation file - and place it at the proper place so that
the usual CI scripts can handle it.
The proper place is for all python projects
$PROJECT/locale/$PROJECT.pot - see setup.cfg.
Further imports will be done by the OpenStack Proposal bot.
Setup also setup.cfg with the usual babel commands and add the default
babel.cfg file.
Change-Id: I583e98fac2f9b84cd1115640b936057ad95957e8
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
Takes a yaml-based config file
(see etc/oslo/routing_notifier.yaml.sample) via
routing_notifier_config option.
Events may be routed by priority or event_type.
Implements: blueprint configurable-notification
Change-Id: I437dfac348f387044e6da3d6a0bbb208323c1741
packages is recursive, so there is no need to list subpackages
versions are set by tags, so the version in the file is not needed
non-d2to1-based pbr does not need the hook specification
Change-Id: Id5e6c19dfe81c630862e9b87b7f9e5f67a965945
This is the ZeroMQ server which acts as a proxy for all messages
destined to a particular host. Again, there are a bunch of FIXMEs
here. This still needs work.
Change-Id: I9384f486e44b0b0cbca028e219ad66f1990d5181
This is apparently fixed in pbr since I3972b3132619e8e2dd7e362ca5fe9d1e3add43b8
but I'm seeing the issue with pbr 0.5.21 on Fedora.
Related-Bug: #1194742
Change-Id: I136b8493c8d8d48a0116facf5f23c2a1479c070f