Open Stack

On 19/06/15 15:01 +0000, Ken Giusti wrote:
>
>
>On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco <flavio at redhat.com> 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.
>
>Clint - can you also include separate metrics for the amqp1 driver? 
>

oslo_messaging/_drivers/protocols/amqp/controller 302 46 0 80 18 82%
oslo_messaging/_drivers/protocols/amqp/driver 134 13 0 28 6 88%
oslo_messaging/_drivers/protocols/amqp/drivertasks 52 5 0 8 2 85%
oslo_messaging/_drivers/protocols/amqp/eventloop 195 43 0 64 18 71%

Cheers,
Flavio

>
> 
>
>    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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>    >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>    --
>    @flaper87
>    Flavio Percoco
>    __________________________________________________________________________
>    OpenStack Development Mailing List (not for usage questions)
>    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150620/6bf70c73/attachment.pgp>