Excerpts from Ken Giusti's message of 2015-06-19 15:01:46 +0000: > On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco <[email protected]> wrote: > > > On 18/06/15 16:37 -0400, Doug Hellmann wrote: > > >Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: > > >> Hello! I know there's been a lot of churn and misunderstanding over the > > >> recent devstack changes, so I wanted to make it clear where we're going > > >> with messaging drivers now that the policy [1] was approved. > > >> > > >> According to the policy, drivers need to have at least 60% unit test > > >> coverage, and an integration test suite with at least 3 "popular" > > >> OpenStack projects, with preference for Nova, Cinder, and Glance, and > > >> individuals who will support said test suite. > > >> > > >> So, with that, the following is the status of each driver in tree right > > >> now: > > >> > > >> rabbit - 89% Unit test coverage. Being the default in devstack, and > > >> the default in nearly every project's config files, this one is heavily > > >> integration tested. There are multiple individuals who have proven to > > >> be able to debug failures related to RabbitMQ and are well known in > > >> the community. > > > > > >+1 > > > > > >> > > >> qpid - Unit test coverage is at 77%, so it passes that bar. I cannot > > >> find any integration testing being done, so it fails that. I also have > > >> not found anyone who will step up and support it. So this should be > > >> deprecated immediately. > > > > > >+1 - I believe Ken and the other folks interested in this indicated that > > >the AMQP 1.0 driver should replace this one. > > > > The qpid driver should be deprecated, I'll be doing so in the next > > couple of days. Look forward to the patch. > > > > +1 > > > > > > >Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is > > >separate from the driver named "qpid"). > > > > I'd like to clarify something about the AMQP 1.0 driver. It's not a > > direct replacement for the qpidd one because it uses an entirely > > different protocol that recently became a standard. > > > > The reason I mention this is because it doesn't really require qpidd - > > not the double d - which is the broker daemon in the qpid family. I > > guess the confusion comes because the library it sits on top off is > > called qpid-proton. > > > > The qpid family is a set of tools that provide messaging capabilities. > > Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 > > library), qpid-dispatch (message router). It's confusing indeed. > > > > The importance of this distinction is that the amqp1.0 driver in > > oslo.messaging is intended as a protocol based driver and not > > targetting any technology. That is to say, that it could be written > > using a library that is not qpid-proton and it can talk to any message > > router or message broker that has support for amqp 1.0. > > > > > +1 - yeah, we really shouldn't be considering the amqp1 driver as simply > the "replacement qpid driver" - as Flavio points out it has the potential > to provide compatibility with other messaging back ends.
OK, sorry for my confusion on that and thanks to you and Flavio for clarifying. > > Clint - can you also include separate metrics for the amqp1 driver? > > > The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 > > plugin enabled) and qpidd. > > > > Since we're at it, let me share some updates: > > > > The driver unittests now run on every python2 job and the work on > > python3 is almost done. There's also a functional tests gate like we > > have for other drivers. > > > > The missing bit is an integration gate, which we'll be start working > > on in the next couple of days. > > > > Hope the above helps clarifying confusions around this driver. > > > > > > > >> > > >> zmq - Unit test coverage is 74%. There are no currently active > > integration > > >> tests in OpenStack's infrastructure. Several individuals have self > > >> identified as being willing to work on creating them. We have not had > > >> the conversations yet about ongoing support. I recommend we continue to > > >> support their effort to become policy compliant. If that does not > > solidify > > >> by M3 of Liberty, or if the "new" zmq driver appears with integration > > >> tests and support manpower, then we can deprecate at that time. > > > > > >+1 - I know interest has been growing in this, so let's keep it going > > >and see where we end up. > > > > > >> > > >> There's also the question of _how_ to deprecate them. I figure we should > > >> deprecate when the driver is loaded. Is there an existing mechanism > > >> that someone can point me to, or should I look at adding that to > > >> oslo.messaging/stevedore? > > > > > >Normally we would recommend using versionutils from oslo.log, but we've > > >been trying to avoid making oslo.log a dependency of the oslo libs > > >because it uses some of them and that introduces cycles. Dims had a > > >patch recently that just used a DeprecationWarning, and relied on > > >oslo.log to redirect the warning to the log file. That seems like a good > > >pattern to repeat. > > > > Can we use debtcollector to decorate the main driver class? A warning > > will be printted every time an instance of such class is created > > (rather than at import time). > > > > If we don't want to add a dependency on that, we could just use a > > DeprecationWarning as Doug mentioned. > > > > > > > >Doug > > > > > >> > > >> [1] > > http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html > > >> > > > > > >__________________________________________________________________________ > > >OpenStack Development Mailing List (not for usage questions) > > >Unsubscribe: > > [email protected]?subject:unsubscribe > > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > > @flaper87 > > Flavio Percoco > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
