Open Stack

Because we’re getting into future development plans, I’ve replied to this in detail in a new thread on the -dev mailing list. Let’s continue the discussion over there to ensure that the rest of the development team can be involved.

http://lists.openstack.org/pipermail/openstack-dev/2014-September/046223.html

Doug


On Sep 17, 2014, at 7:54 AM, James Page <james.page at ubuntu.com> wrote:

> Signed PGP part
> Hi Li
> 
> On 17/09/14 11:58, Li Ma wrote:
> >> The scale potential is very appealing and is something I want to
> >> test - - hopefully in the next month or so.
> >>
> >> Canonical are interested in helping to maintain this driver and
> >> hopefully we help any critical issues prior to Juno release.
> >>
> >>
> > That sounds good. I just went through all the bugs reported in the
> > community.
> >
> > The only critical bug which makes ZeroMQ malfunction is
> > https://bugs.launchpad.net/oslo.messaging/+bug/1301723 and the
> > corresponding review is under way:
> > https://review.openstack.org/#/c/84938/
> 
> Agreed
> 
> > Others are tagged to 'zmq' in
> > https://bugs.launchpad.net/oslo.messaging
> 
> Looking through Doug's suggested list of information and collating
> what I know of from our work last week:
> 
> 1) documentation for how to configure and use zeromq with
> oslo.messaging (note, not the version in oslo-incubator, the version
> in the messaging library repository)
> 
> As part of our sprint, I worked on automating deployment of OpenStack
> + 0MQ using Ubuntu + Juju (service orchestration tool). I can re-jig
> that work into some general documentation on how best to configure
> ZeroMQ with OpenStack - the current documentation is a bit raw and
> does not talk about how to configure the oslo-messaging-zmq-receiver
> at all.
> 
> I also plan some packaging updates for Debian/Ubuntu in our next dev
> cycle to make this a little easier to configure and digest - for
> example, right now no systemd unit/upstart configuration/sysv init
> script is provided to manage the zmq-receiver.
> 
> I'd also like to document the current design of the ZMQ driver - Doug
> - where is the best place todo this? I thought in the source tree
> somewhere.
> 
> 2) a list of the critical bugs that need to be fixed + any existing
> patches associated with those bugs, so they can be reviewed early in kilo
> 
> This blocks operation of nova+neutron environements:
> 
> https://bugs.launchpad.net/oslo.messaging/+bug/1301723
> 	Summary: Message was sent to wrong node with zmq as rpc_backend
> 	Patch: https://review.openstack.org/84938
> 
> Also notifcations are effectively unimplemented which prevents use
> with Ceilometer so I'd also add:
> 
> https://bugs.launchpad.net/oslo.messaging/+bug/1368154
> 	Summary: https://bugs.launchpad.net/oslo.messaging/+bug/
> 	Patch: https://review.openstack.org/120745
> 
> 3) an analysis of what it would take to be able to run functional
> tests for zeromq on our CI infrastructure, not necessarily the full
> tempest run or devstack-gate job, probably functional tests we place
> in the tree with the driver (we will be doing this for all of the
> drivers) + besides writing new functional tests, we need to bring the
> unit tests for zeromq into the oslo.messaging repository
> 
> Kapil Thangavelu started work on both functional tests for the ZMQ
> driver last week; the output from the sprint is here:
> 
>    https://github.com/ostack-musketeers/oslo.messaging
> 
> it covers the ZMQ driver (including messaging through the zmq-receiver
> proxy) and the associated MatchMakers (local, ring, redis) at a
> varying levels of coverage, but I feel it moves things in the right
> direction - Kapil's going to raise a review for this in the next
> couple of days.
> 
> Doug - has any structure been agreed within the oslo.messaging tree
> for unit/functional test splits? Right now we have them all in one place.
> 
> Edward Hope-Morley also worked on getting devstack working with ZMQ:
> 
>    https://github.com/ostack-musketeers/devstack
> 
> that's still WIP but again we'll get any changes submitted for review
> ASAP.
> 
> 4) and some improvements that we would like to make longer term
> 
> a) Connection re-use on outbound messaging avoiding the current tcp
> setup overhead for every sent message.  This may also bring further
> performance benefits due to underlying messaging batching in ZMQ.
> 
> b) Moving from tcp PUSH/PULL sockets between servers to DEALER/DEALER
> (or something similar) to allow for heartbeating and more immediate
> failure detection
> 
> c) Crypto support
> 
> Cheers
> 
> James
> 
> --
> James Page
> Ubuntu and Debian Developer
> james.page at ubuntu.com
> jamespage at debian.org
>