Open Stack

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.

Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is
separate from the driver named "qpid").

> 
> 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.

Doug

> 
> [1] http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html
>