Open Stack

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.


>
>>
>>> 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)