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 <mba...@redhat.com> wrote:
>
>
> Roman Podoliaka <rpodoly...@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 <e...@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-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
>
> __________________________________________________________________________
> 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

Reply via email to