Open Stack

On 08/27/2014 03:35 PM, Ken Giusti wrote:
> Hi All,
> 
> I believe Juno-3 is our last chance to get this feature [1] included
> into olso.messaging.
> 
> I honestly believe this patch is about as low risk as possible for a
> change that introduces a whole new transport into oslo.messaging.  The
> patch shouldn't affect the existing transports at all, and doesn't
> come into play unless the application specifically turns on the new
> 'amqp' transport, which won't be the case for existing applications.
> 
> The patch includes a set of functional tests which exercise all the
> messaging patterns, timeouts, and even broker failover. These tests do
> not mock out any part of the driver - a simple test broker is included
> which allows the full driver codepath to be executed and verified.
> 
> IFAIK, the only remaining technical block to adding this feature,
> aside from core reviews [2], is sufficient infrastructure test coverage.
> We discussed this a bit at the last design summit.  The root of the
> issue is that this feature is dependent on a platform-specific library
> (proton) that isn't in the base repos for most of the CI platforms.
> But it is available via EPEL, and the Apache QPID team is actively
> working towards getting the packages into Debian (a PPA is available
> in the meantime).
> 
> In the interim I've proposed a non-voting CI check job that will
> sanity check the new driver on EPEL based systems [3].  I'm also
> working towards adding devstack support [4], which won't be done in
> time for Juno but nevertheless I'm making it happen.
> 
> I fear that this feature's inclusion is stuck in a chicken/egg
> deadlock: the driver won't get merged until there is CI support, but
> the CI support won't run correctly (and probably won't get merged)
> until the driver is available.  The driver really has to be merged
> first, before I can continue with CI/devstack development.
> 
> [1] https://blueprints.launchpad.net/oslo.messaging/+spec/amqp10-driver-implementation
> [2] https://review.openstack.org/#/c/75815/
> [3] https://review.openstack.org/#/c/115752/
> [4] https://review.openstack.org/#/c/109118/


Hi Ken,

Thanks a lot for your hard work here. As I stated in my last comment on
the driver's review, I think we should let this driver land and let
future patches improve it where/when needed.

I agreed on letting the driver land as-is based on the fact that there
are patches already submitted ready to enable the gates for this driver.

Lets see what others think about this,
Flavio

-- 
@flaper87
Flavio Percoco