[openstack-dev] [all] QPID incompatible with python 3 and untested in gate -- what to do?
doug at doughellmann.com
Wed Apr 15 18:59:35 UTC 2015
Excerpts from Clint Byrum's message of 2015-04-15 11:02:34 -0700:
> Excerpts from Doug Hellmann's message of 2015-04-15 10:48:30 -0700:
> > Excerpts from Clint Byrum's message of 2015-04-15 10:15:11 -0700:
> > > Excerpts from Sean Dague's message of 2015-04-14 16:54:30 -0700:
> > > >
> > > > It's time to be honest about the level of support that comes with those
> > > > other backends, deprecate the plugability, and move on to more
> > > > interesting problems. We do have plenty of them to solve. :) Perhaps in
> > > > doing so we could get a better Rabbit implementation and make life
> > > > easier for everyone.
> > > >
> > >
> > > I think you're right about most of this, so +1*
> > >
> > > *I want to suggest that having this pluggable isn't the problem. Merging
> > > drivers without integration testing and knowledgeable resources from
> > > interested parties is the problem. If there isn't a well defined gate
> > > test, and a team of people willing to respond to any and all issues with
> > > that infrastructure committed, then the driver should not be shipped
> > > with oslo.messaging.
> > I tend to agree, although it's up to the oslo-messaging-core team to
> > decide what they want to support.
> > A general note on these sorts of conversations:
> > It's very easy to look at the state of OpenStack testing now and
> > say, "we must have integration test jobs for oslo.messaging!" Don't
> > forget that most of the work in this repo came out of Nova at a
> > time when there was no such thing, and we've only just settled on
> > good processes for managing third-party testing of that sort in
> > Nova, Cinder, and Neutron. We've been watching that work with
> > interest, but given the small size of the team currently maintaining
> > the library, it wasn't necessarily the highest priority.
> > That said, I know Mehdi and others have been working on setting up
> > integration test jobs, and I expect that at some point in the
> > not-too-distant future we'll need to discuss putting a rule into
> > place for these drivers just like the other projects have for their
> > drivers. We don't yet have a sufficiently strong test suite to do
> > that, though, so requiring test jobs now would be premature.
> Great points Doug.
> A devstack-gate job that is pointed at the major consumers of
> oslo.messaging would be enough I think. The library sits at the core
> of nearly everything, so I don't think we necessarily need to have
> a split-out gate that just tests oslo.messaging narrowly with each
> backend. Somewhere we would need _something_ in the gate using a
> particular driver to be able to say that one should use it.
Sure, that makes sense.
More information about the OpenStack-dev