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 <[email protected]> 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 > [email protected] > [email protected] > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
