Open Stack

On 09/18/2014 04:16 PM, Kapil Thangavelu wrote:
> 
> 
> On Thu, Sep 18, 2014 at 4:18 AM, Flavio Percoco <flavio at redhat.com
> <mailto:flavio at redhat.com>> wrote:
> 
>     On 09/17/2014 04:34 PM, Doug Hellmann wrote:
>     > This thread [1] has turned more “future focused", so I’m moving the conversation to the -dev list where we usually have those sorts of discussions.
>     >
>     > [1] http://lists.openstack.org/pipermail/openstack/2014-September/009253.html
>     >
> 
> 
>     I saw this mentioned in the `openstack` thread but I'd like us to
>     reconsider it.
> 
>     Since we've gone through the "hey please don't deprecate it, I'll help"
>     process a couple of times with the zmq driver, I'm thinking we should
>     pull it out of the code base anyway.
> 
> 
> I think the primary issue has been two fold, one is the lack of
> reviews/merges on extant patches that fix critical items that have been
> outstanding for months. I think that is compounded by the other issue
> which was the lack of tests. We've sprinted last week on adding in both
> unit tests, the extant patches and functionally verifying them by
> automating cloud deployments with zmq for the messaging driver. We're
> also committing as a company to supporting it on an ongoing basis. If we
> get the gates going for kilo, i don't see any reason for the churn
> below, if the gates don't get going we can yank to external in kilo anyway.

The above sounds good to me. Thanks for sharing.

Can we have a deadline for all this? Last time we discussed zmq driver's
faith, we said that k-1 was a good deadline for it to get back in shape.
If the above plan sounds good to other folks, then I'd prefer us to
stick to k-1 for all the above to happen.

Thoughts?

Thanks again, Kapil
Flavio

>  
> cheers,
> 
> Kapil
> 
> 
>     Here's a rough plan of what I think we should do until the zmq is
>     updated and has a proper gate working:
> 
>     1. Pull it out the code base into its own repo (stackforge?)
>     2. Setup the basic `oslo.messaging` gates for it
>     3. Release the driver on pypi as: `oslo.messaging.zmq`
>     4. Make lots of noise and make sure people using zmq knows that they
>     have to install a separate package now. (I know this means creating a
>     new package for many distros).
> 
>     If there are folks interested in maintaining this driver, they can still
>     do it with the driver outside the code base. If it ever gets enough
>     attention and maturity, it could be re-proposed for inclusion into the
>     code base.
> 
>     I know there are folks interested in a broker-less solution and we now
>     have the not-tested-in-production-yet amqp1.0 driver which I think is a
>     very good solution and also shares most of the semantics we rely on
>     protocol-wise.
> 
>     I didn't go through the whole thread so, I'm sorry if I'm repeating
>     something that has already been said/proposed/discussed.
> 
>     Flavio
> 
>     > On Sep 17, 2014, at 7:54 AM, James Page <james.page at ubuntu.com
>     <mailto: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.
>     >
>     > The documentation in the oslo.messaging repository [2] would be a
>     good place to start for that. If we decide deployers/operators need
>     the information we can either refer to it from the guides managed by
>     the documentation team or we can move/copy the information. How
>     about if you start a new drivers subdirectory there, and add
>     information about zmq. We can have other driver authors provide
>     similar detail about their drivers in the same directory.
>     >
>     > [2]
>     http://git.openstack.org/cgit/openstack/oslo.messaging/tree/doc/source
>     >
>     >>
>     >> 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
>     >
>     > That’s a good list, and shorter than I expected. I have added
>     these bugs to the next-kilo milestone.
>     >
>     >>
>     >> 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.
>     >
>     > I think we will want them split up, but we don’t have an agreed
>     existing structure for that. I would like to see a test framework of
>     some sort that defines the tests in a way that can be used to run
>     the same functional for all of the drivers as separate jobs (with
>     appropriate hooks for ensuring the needed services are running,
>     etc.). Setting that up warrants its own spec, because there are
>     going to be quite a few details to work out. We will also need to
>     participate in the larger conversation about how to set up those
>     functional test jobs to be consistent with the other projects.
>     >
>     >>
>     >> 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.
>     >
>     > That’s good to have, but I don’t necessarily consider it a
>     requirement for in-project functional tests.
>     >
>     >>
>     >> 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.
>     >
>     > This sounds like it would be a good thing to do, but making what
>     we have work correctly and testing it feels more important for now.
>     >
>     >>
>     >> b) Moving from tcp PUSH/PULL sockets between servers to DEALER/DEALER
>     >> (or something similar) to allow for heartbeating and more immediate
>     >> failure detection
>     >
>     > I would need to understand how much of a rewrite that represents
>     before commenting further.
>     >
>     >>
>     >> c) Crypto support
>     >
>     > There are some other discussions about adding crypto to messaging,
>     and I hope we can do that without having to touch each driver, if
>     possible.
>     >
>     >>
>     >> Cheers
>     >>
>     >> James
>     >>
>     >> --
>     >> James Page
>     >> Ubuntu and Debian Developer
>     >> james.page at ubuntu.com <mailto:james.page at ubuntu.com>
>     >> jamespage at debian.org <mailto:jamespage at debian.org>
>     >>
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
> 
> 
>     --
>     @flaper87
>     Flavio Percoco
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


-- 
@flaper87
Flavio Percoco