Open Stack

The oslo.messaging session at the summit [1] resulted in some plans to evolve how oslo.messaging works, but probably not during this cycle.

First, we talked about what to do about the various drivers like ZeroMQ and the new AMQP 1.0 driver. We decided that rather than moving those out of the main tree and packaging them separately, we would keep them all in the main repository to encourage the driver authors to help out with the core library (oslo.messaging is a critical component of OpenStack, and we’ve lost several of our core reviewers for the library to other priorities recently).

There is a new set of contributors interested in maintaining the ZeroMQ driver, and they are going to work together to review each other’s patches. We will re-evaluate keeping ZeroMQ at the end of Kilo, based on how things go this cycle.

We also talked about the fact that the new version of Kombu includes some of the features we have implemented in our own driver, like heartbeats and connection management. Kombu does not include the calling patterns (cast/call/notifications) that we have in oslo.messaging, but we may be able to remove some code from our driver and consolidate the qpid and rabbit driver code to let Kombu do more of the work for us.

Python 3 support is coming slowly. There are a couple of patches up for review to provide a different sort of executor based on greenio and trollius. Adopting that would require some application-level changes to use co-routines, so it may not be an optimal solution even though it would get us off of eventlet. (During the Python 3 session later in the week we talked about the possibility of fixing eventlet’s monkey-patching to allow us to use the new eventlet under python 3.)

We also talked about the way the oslo.messaging API uses URLs to get some settings and configuration options for others. I thought I remembered this being a conscious decision to pass connection-specific parameters in the URL, and “global” parameters via configuration settings. It sounds like that split may not have been implemented as cleanly as originally intended, though. We identified documenting URL parameters as an issue for removing the configuration object, as well as backwards-compatibility. I don’t think we agreed on any specific changes to the API based on this part of the discussion, but please correct me if your recollection is different.

We also learned that there is a critical bug [2] related to heartbeats for RabbitMQ, and we have a few patches up to propose fixes in different ways (see the bottom of [1]). This highlighted again the fact that we have a shortage of reviewers for oslo.messaging.

Doug

[1] https://etherpad.openstack.org/p/kilo-oslo-oslo.messaging
[2] https://bugs.launchpad.net/nova/+bug/856764