[openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
james.page at ubuntu.com
Mon Nov 17 14:26:20 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
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 ) . 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.
> 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.
> 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.
> 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...
> 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
Ubuntu and Debian Developer
james.page at ubuntu.com
jamespage at debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the OpenStack-dev