Open Stack

Mike,

I can't agree more: as far as we are concerned, every service is yet
another WSGI app. And it should be left up to operator, how to deploy
it.

So 'green thread awareness' (i.e. patching of the world) should go to
separate keystone|*-eventlet binary, while everyone else will still be
able to use it as a general WSGI app.

Thanks,
Roman

On Thu, Jan 29, 2015 at 6:55 PM, Mike Bayer <mbayer at redhat.com> wrote:
>
>
> Roman Podoliaka <rpodolyaka at mirantis.com> wrote:
>
>>
>> On native threads vs green threads: I very much like the Keystone
>> approach, which allows to run the service using either eventlet or
>> Apache. It would be great, if we could do that for other services as
>> well.
>
> but why do we need two approaches to be at all explicit?   Basically, if you write a WSGI application, you normally are writing non-threaded code with a shared nothing approach.  Whether the WSGI app is used in a threaded apache container or a gevent style uWSGI container is a deployment option.  This shouldn’t be exposed in the code.
>
>
>
>
>>
>> Thanks,
>> Roman
>>
>> On Thu, Jan 29, 2015 at 5:54 PM, Ed Leafe <ed at leafe.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 01/28/2015 06:57 PM, Johannes Erdfelt wrote:
>>>
>>>> Not sure if it helps more than this explanation, but there was a
>>>> blueprint and accompanying wiki page that explains the move from twisted
>>>> to eventlet:
>>>
>>> Yeah, it was never threads vs. greenthreads. There was a lot of pushback
>>> to relying on Twisted, which many people found confusing to use, and
>>> more importantly, to follow when reading code. Whatever the performance
>>> difference may be, eventlet code is a lot easier to follow, as it more
>>> closely resembles single-threaded linear execution.
>>>
>>> - --
>>>
>>> - -- Ed Leafe
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2.0.14 (GNU/Linux)
>>>
>>> iQIcBAEBAgAGBQJUyle8AAoJEKMgtcocwZqLRX4P/j3LhEhubBOJmWepfO6KrG9V
>>> KxltAshKRvZ9OAKlezprZh8N5XUcxRTDxLhxkYP6Qsaf1pxHacAIOhLRobnV5Y+A
>>> oF6E6eRORs13pUhLkL+EzZ07Kon+SjSmvDDZiIo+xe8OTbgfMpo5j7zMPeLJpcr0
>>> RUSS+knJ/ewNCMaX4gTwTY3sDYFZTbVuGHFUtjSgeoJP0T5aP05UR73xeT7/AsbW
>>> O8dOL4tX+6GcxIHyX4XdFH9hng1P2vBZJ5l8yV6BxB6U8xsiQjlsCpwrb8orYJ0r
>>> f7+YW0D0FHOvY/TV4dzsLC/2NGc2AwMszWL3kB/AzbUuDyMMDEGpbAS/VHDcyhZg
>>> l7zFKEQy+9UybVzWjw764hpzcUT/ICPbTBiX/QuN4qY9YTUNTlCNrRAslgM+cr2y
>>> x0/nb6cd+Qq21RPIygJ9HavRqOm8npF6HpUrE55Dn+3/OvfAftlWNPcdlXAjtDOt
>>> 4WUFUoZjUTsNUjLlEiiTzgfJg7+eQqbR/HFubCpILFQgOlOAuZIDcr3g8a3yw7ED
>>> wt5UZz/89LDQqpF2TZX8lKFWxeKk1CnxWEWO208+E/700JS4xKHpnVi4tj18udsY
>>> AHnihUwGO4d9Q0i+TqbomnzyqOW6SM+gDUcahfJ92IJj9e13bqpbuoN/YMbpD/o8
>>> evOz8G3OeC/KaOgG5F/1
>>> =1M8U
>>> -----END PGP SIGNATURE-----
>>>
>>> __________________________________________________________________________
>>> 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
>
> __________________________________________________________________________
> 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