Open Stack

Hey all,

I went ahead and pushed up a WIP patch taking into account suggestions from
Dims and Doug. I just saw the email from Adam before I put up the patch.

Let me know if this is somewhat the direction that we want to take:
https://review.openstack.org/#/c/34834/

Thanks all for your time in responding to this. The feedback helps out a
lot!


Best Regards,

Lance Bragstad
Software Engineer - OpenStack
Cloud Solutions and OpenStack Development
T/L 553-5409, External 507-253-5409
ldbragst at us.ibm.com, Bld 015-2/C118



From:	Adam Young <ayoung at redhat.com>
To:	openstack-dev at lists.openstack.org,
Date:	06/27/2013 10:37 PM
Subject:	Re: [openstack-dev] [Keystone] Unified logging and Eventlet
            conflict



On 06/27/2013 08:43 AM, Davanum Srinivas wrote:
> Lance, Doug,
> Looks like eventlet.patcher.is_monkey_patched(thread) is a reasonable
> check to switch to to a thread-local implementation.

Doesn't it make more sense to have anything Eventlet based explicitly
activated?  For Keystone, we have isolated all monkeypatching to be done
by the process that starts the Keystone server.  Adding an additional
call in there to activate the thread local storage for greenthreads is
reasonable from our perspective.

>
> Doug,
> did you mean threading.local with WeakValueDictionary?
>
> -- dims
>
> On Thu, Jun 27, 2013 at 8:15 AM, Doug Hellmann
> <doug.hellmann at dreamhost.com> wrote:
>> This isn't something the deployer controls, so I don't know if we want
it to
>> go into a config setting.
>>
>> If we can't detect eventlet being used automatically, we could provide
an
>> initialization function in the locals module so projects could change
the
>> behavior when a process starts. The default mode would need to be
eventlet,
>> for now, but a thread-local implementation seems like an obvious
>> alternative. And of course we would need the module to behave as it does
now
>> if the initialization is not explicitly called.
>>
>> Doug
>>
>> On Thu, Jun 27, 2013 at 8:03 AM, Davanum Srinivas <davanum at gmail.com>
wrote:
>>> Lance,
>>>
>>> "is eventlet installed" a strong enough check? given that folks may
>>> pick up a python install that has eventlet installed w/o realizing it?
>>>
>>> Is there a way to check if the openstack process the code is running
>>> in is using eventlet or not? or the other choice is a flag in logging
>>> conf to switch to a non-eventlet implemenation?
>>>
>>> -- dims
>>>
>>> On Wed, Jun 26, 2013 at 8:17 PM, Lance D Bragstad <ldbragst at us.ibm.com>
>>> wrote:
>>>> Hey all,
>>>>
>>>> Recently there has been some push to get a unified logging
>>>> implementation
>>>> pulled from Oslo-incubator into Keystone (Blueprint:
>>>>
>>>>
https://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone
).
>>>> Keystone has been actively working to isolate eventlet code within
>>>> Keystone
>>>> and bringing in the current implementation from Oslo-incubator would
go
>>>> against that work, as /oslo-incubator/openstack/common/log.py imports
>>>> /oslo-incubator/openstack/common/local.py which has a dependency on
>>>> eventlet
>>>>
>>>> (
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/local.py#L22
)
>>>> and is used for storing references to contexts. I know there has been
a
>>>> couple of projects looking to not be dependent on eventlet and thought
>>>> this
>>>> might be a good topic for the mailing list, especially if these
changes
>>>> end
>>>> up in Oslo-incubator.
>>>>
>>>> After discussion with a couple of the Keystone members, one option is
to
>>>> tweak local.py to check if eventlet is even installed (similar to def
>>>> _ensure_subprocess here:
>>>>
>>>>
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py#L11
)
>>>> and if it isn't then try implementing a different WeakLocal store not
>>>> using
>>>> corolocal.local. Any other ideas on how to approach this are more than
>>>> welcome. Thanks!
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Lance Bragstad
>>>> Software Engineer - OpenStack
>>>> Cloud Solutions and OpenStack Development
>>>> T/L 553-5409, External 507-253-5409
>>>> ldbragst at us.ibm.com, Bld 015-2/C118
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130627/9c1cc198/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130627/9c1cc198/attachment.gif>