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.hellm...@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 <dava...@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 <ldbra...@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
ldbra...@us.ibm.com, Bld 015-2/C118
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
