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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev