On Wed, Apr 15, 2015 at 8:18 PM, Joshua Harlow <harlo...@outlook.com> wrote: > Ken Giusti wrote: >> >> On Wed, Apr 15, 2015 at 1:33 PM, Doug Hellmann<d...@doughellmann.com> >> wrote: >>> >>> Excerpts from Ken Giusti's message of 2015-04-15 09:31:18 -0400: >>>> >>>> On Tue, Apr 14, 2015 at 6:23 PM, Joshua Harlow<harlo...@outlook.com> >>>> wrote: >>>>> >>>>> Ken Giusti wrote: >>>>>> >>>>>> Just to be clear: you're asking specifically about the 0-10 based >>>>>> impl_qpid.py driver, correct? This is the driver that is used for >>>>>> the "qpid://" transport (aka rpc_backend). >>>>>> >>>>>> I ask because I'm maintaining the AMQP 1.0 driver (transport >>>>>> "amqp://") that can also be used with qpidd. >>>>>> >>>>>> However, the AMQP 1.0 driver isn't yet Python 3 compatible due to its >>>>>> dependency on Proton, which has yet to be ported to python 3 - though >>>>>> that's currently being worked on [1]. >>>>>> >>>>>> I'm planning on porting the AMQP 1.0 driver once the dependent >>>>>> libraries are available. >>>>>> >>>>>> [1]: https://issues.apache.org/jira/browse/PROTON-490 >>>>> >>>>> >>>>> What's the expected date on this as it appears this also blocks python >>>>> 3 >>>>> work as well... Seems like that hasn't been updated since nov 2014 >>>>> which >>>>> doesn't inspire that much confidence (especially for what appears to be >>>>> mostly small patches). >>>>> >>>> Good point. I reached out to the bug owner. He got it 'mostly >>>> working' but got hung up on porting the proton unit tests. I've >>>> offered to help this along and he's good with that. I'll make this a >>>> priority to move this along. >>>> >>>> In terms of availability - proton tends to do releases about every 4-6 >>>> months. They just released 0.9, so the earliest availability would be >>>> in that 4-6 month window (assuming that should be enough time to >>>> complete the work). Then there's the time it will take for the >>>> various distros to pick it up... >>>> >>>> so, definitely not 'real soon now'. :( >>> >>> This seems like a case where if we can get the libs we need to a point >>> where they install via pip, we can let the distros catch up instead of >>> waiting for them. >>> >> >> Sadly just the python wrappers are available via pip. Its C extension >> requires that the native proton shared library (libqpid-proton) is >> available. To date we've relied on the distro to provide that >> library. > > > How does that (c extension) work with eventlet? Does it? >
I haven't experienced any issues in my testing. To be clear - the libqpid-proton library is non-blocking and non-threading. It's simply an protocol processing engine - the driver hands it raw network data and messages magically pop out (and vise versa). All I/O, blocking, threading etc is done in the python driver itself. I suspect there's nothing eventlet needs to do that requires overloading functionality provided by the binary proton library, but my knowledge of eventlet is pretty slim. > >> >>> Similarly, if we have *an* approach for Python 3 on oslo.messaging, that >>> means the library isn't blocking us from testing applications with >>> Python 3. If some of the drivers lag, their test jobs may need to be >>> removed or disabled if the apps start testing under Python 3. >>> >>> Doug >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ken Giusti (kgiu...@gmail.com) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev