Open Stack

On Fri, Jun 19, 2015 at 4:47 PM Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Ken Giusti's message of 2015-06-19 08:01:46 -0700:
> > 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?
> >
>
> It's far less clear to me how to measure the unit test coverage of the
> amqp driver. I'll wait for Flavio's answer to my question about where
> the code lives, because it is definitely not organized like the others.
>
>
No, it isn't.  At the time we proposed this structure for the amqp1 driver,
there really wasn't much formal structure within the driver directory.  We
had impl_rabbit, which was copied to impl_qpid in the hopes that all the
rest of the code could be shared (it didn't work out very well).  And the
zmq code wasn't working at the time.  And all of it was crammed into one
flat directory.

Rather than heap yet more stuff into that directory, we proposed to put the
amqp1 driver into its own sub-directory.  We chose a 'protocols'
subdirectory, into which the amqp1 driver lives in the 'amqp'
subdirectory.  The hope was that other protocols would put their
implementation bits into that protocols directory rather than lump them in
directly under _drivers.

It looks like the zmq driver will be structured a bit different from that -
there will be a top level impl_zmq file along side a zmq_driver directory.

I like the way zmq has laid out the sources, and maybe that should be the
'official' structure to olso.messaging drivers.  If that's the case I'll be
more that happy to arrange the amqp1 driver in a similar manner.

I've gone off into the weeds, sorry.

The amqp1 driver lives in _drivers/protocols/amqp directory (for now).  And
yes, those unit tests should be in the tests/drivers directory like
everything else - when the tests/drivers directory was created that file
wasn't moved.  Oversight - I'll submit a patch to fix it.

As far as coverage testing is concerned - I'm not sure how best to do this
accurately.  The amqp1 driver doesn't use any of the code in amqpdriver.py,
amqp.py, common.py (I think), matchmaker*, pool.py, and certainly not
anything in impl_*.py.  So zero coverage of those files is expected.  The
amqp1 driver simply subclasses base.py, and that's about it from that top
level directory.




__________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150619/725f7313/attachment.html>