Doug Hellmann wrote:
On Nov 17, 2014, at 10:01 AM, Denis Makogon<>  wrote:

On Mon, Nov 17, 2014 at 4:26 PM, James Page<>  wrote:

Hash: SHA256

Hi Denis

On 17/11/14 07:43, Denis Makogon wrote:
During Paris Design summit oslo.messaging session was raised good
question about maintaining ZeroMQ driver in upstream (see section
“dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
know, good thoughts are comming always after. I’d like to propose
several improvements in process of maintaining and developing of
ZeroMQ driver in upstream.

Contribution focus. As we all see, that there are enough patches
that are trying to address certain problems related to ZeroMQ

Few of them trying to add functional tests, which is definitely
good, but … there’s always ‘but’, they are not “gate”-able.
I'm not sure I understand you statement about them not being
"gate"-able - the functional/unit tests currently proposed for the zmq
driver run fine as part of the standard test suite execution - maybe
the confusion is over what 'functional' actually means, but in my
opinion until we have some level of testing of this driver, we can't
effectively make changes and fix bugs.

I do agree that there's a confusion what "functional testing" means.
Another thing, what the best solution is? Unit tests are welcome, but they
are still remain to be units (they are using mocks, etc.)
I'd try to define what 'fuctional testing' means for me. Functional testing
in oslo.messaging means that we've been using real service for messaging
(in this case - deployed 0mq). So, the simple definition, in term os
OpenStack integration, we should be able to run full Tempest test suit for
OpenStack services that are using oslo.messaging with enabled zmq driver.
Am i right or not?

That’s a good goal, but that’s not what I had in mind for in-tree functional 

We should build a simple app using the Oslo libraries that we can place in the 
oslo.messaging source tree to use for exercising the communication patterns of 
the library with different drivers. Ideally that would be a single app (or set 
of apps) that could be used to test all drivers, with tests written against the 
app rather than the driver. Once we have the app and tests, we can define a new 
gate job to run those tests just for oslo.messaging, with a different 
configuration for each driver we support.


An interesting idea that might be useful that taskflow implemented/has done...

The examples @ all get tested during unit test runs to ensure they work as expected. This seems close to your 'simple app' (where app is replaced with example), it might be nice to have a similar approach for oslo.messaging that has 'examples' that are these apps that get ran to probe the functionality of oslo.messaging (as well as useful for documentation to show people how to use it, which is the other usage taskflow has for these examples)

The hacky example tester could likely be shared (or refactored, since it probably needs it),

My proposal for this topic is to change contribution focus from
oslo.messaging by itself to OpenStack/Infra project and DevStack
(subsequently to devstack-gate too).

I guess there would be questions “why?”.  I think the answer is
pretty obvious: we have driver that is not being tested at all
within DevStack and project integration.
This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.

For example says about adding
functional and units. I'm ok with units, but what about functional tests?
Which oslo.messaging gate job runs them?

Also i’d say that such focus re-orientation would be very useful
as source of use cases and bugs eventually. Here’s a list of what
we, as team, should do first:


Ensure that DevStack can successfully:


Install ZeroMQ.


Configure  each project to work with zmq driver from


Ensure that we can run successfully simple test plan for each
project (like boot VM, fill object store container, spin up volume,
A better objective would be able to run a full tempest test as
conducted with the RabbitMQ driver IMHO.

I do agree with this too. But we should define step-by-step plan for this
type of testing. Since we want to see quick gate feedback adding full test
suit would be an overhead, at least for now.

ZeroMQ driver maintainers communityorganization. During design
session was raised question about who uses zmq driver in

I’ve seen folks from Canonical and few other companies. So, here’s
my proposals around improving process of maintaining of given


With respect to best practices of driver maintaining procedure, we
might need to set up community sub-group. What would it give to us
and to the project subsequently? It’s not pretty obvious, at least
for now, but i’d try to light out couple moments:


continuous driver stability


continuous community support (across all OpenStack Project that are
using same model: driver should have maintaining team, would it be
a company or community sub-group)


As sub-group we would need to have our own weekly meeting. Separate
meeting would keep us, as sub-group, pretty focused on zmq driver
only (but it doesn’t mean that we should not participate in regular
meetings). Same question. What it would give us and to the project?
I’d say that the only one valid answer is: we’d not disturb other
folk that are not actually interested in given topic and in zqm
drive too.
I'd prefer that we continue to discuss ZMQ on the broader
oslo.messaging context; I'm keen that the OpenStack community
understands that we want ZMQ to be a first tier driver like qpid and
rmq, and I'm not convinced that pushing discussion out to a separate
sub-group enforces that message...

The only thing that i'm woried about is that we could eventually eat all
meeting time. That's why i try to build out drive maintaining/contribution
team for zmq drive since there were not so may hands when was raised
question about who uses zqm driver.

So, in the end, taking into account words above i’d like to get
feedback from all folks. I’m pretty open for discussion, and if
needed i can commit myself for driving such activities in
- --
James Page
Ubuntu and Debian Developer
Version: GnuPG v1


OpenStack-dev mailing list

Best regards,
Denis M.
OpenStack-dev mailing list

OpenStack-dev mailing list

Sent with Postbox <>

OpenStack-dev mailing list

Reply via email to