[openstack-dev] [all] QPID incompatible with python 3 and untested in gate -- what to do?

Attila Fazekas afazekas at redhat.com
Thu Apr 16 15:39:26 UTC 2015





----- Original Message -----
> From: "Ken Giusti" <kgiusti at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Thursday, April 16, 2015 4:47:50 PM
> Subject: Re: [openstack-dev] [all] QPID incompatible with python 3 and untested in gate -- what to do?
> 
> On Wed, Apr 15, 2015 at 8:18 PM, Joshua Harlow <harlowja at outlook.com> wrote:
> > Ken Giusti wrote:
> >>
> >> On Wed, Apr 15, 2015 at 1:33 PM, Doug Hellmann<doug at 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<harlowja at 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.
> 

Usually to make a C code I/O lib eventlet friendly you need to use python
sockets. It is possible to explicitly use python socket on the C code.
For. Ex.: https://github.com/esnme/ultramysql/blob/master/python/io_cpython.c#L100

If the driver using python sockets and just passing the data to the C code as you said,
it is fine!

> >
> >>
> >>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> --
> Ken Giusti  (kgiusti at gmail.com)
> 
> __________________________________________________________________________
> 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
> 



More information about the OpenStack-dev mailing list