<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 11:35 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 06/27/2013 08:43 AM, Davanum Srinivas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lance, Doug,<br>
Looks like eventlet.patcher.is_monkey_<u></u>patched(thread) is a reasonable<br>
check to switch to to a thread-local implementation.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div style>In principle does, but I think that would require more changes. When we get to the point where other services aren't using eventlet, it might make sense to change the default (OTOH, we may be able to drop the use of the locals module altogether at that point, too, I don't know).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Doug,<br>
did you mean threading.local with WeakValueDictionary?<br></blockquote></div></div></blockquote><div><br></div><div style>Yes, that looks like it would let us match up the semantics.</div><div style><br></div><div style>
Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- dims<br>
<br>
On Thu, Jun 27, 2013 at 8:15 AM, Doug Hellmann<br>
<<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This isn't something the deployer controls, so I don't know if we want it to<br>
go into a config setting.<br>
<br>
If we can't detect eventlet being used automatically, we could provide an<br>
initialization function in the locals module so projects could change the<br>
behavior when a process starts. The default mode would need to be eventlet,<br>
for now, but a thread-local implementation seems like an obvious<br>
alternative. And of course we would need the module to behave as it does now<br>
if the initialization is not explicitly called.<br>
<br>
Doug<br>
<br>
On Thu, Jun 27, 2013 at 8:03 AM, Davanum Srinivas <<a href="mailto:davanum@gmail.com" target="_blank">davanum@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lance,<br>
<br>
"is eventlet installed" a strong enough check? given that folks may<br>
pick up a python install that has eventlet installed w/o realizing it?<br>
<br>
Is there a way to check if the openstack process the code is running<br>
in is using eventlet or not? or the other choice is a flag in logging<br>
conf to switch to a non-eventlet implemenation?<br>
<br>
-- dims<br>
<br>
On Wed, Jun 26, 2013 at 8:17 PM, Lance D Bragstad <<a href="mailto:ldbragst@us.ibm.com" target="_blank">ldbragst@us.ibm.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
Recently there has been some push to get a unified logging<br>
implementation<br>
pulled from Oslo-incubator into Keystone (Blueprint:<br>
<br>
<a href="https://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone" target="_blank">https://blueprints.launchpad.<u></u>net/keystone/+spec/unified-<u></u>logging-in-keystone</a>).<br>
Keystone has been actively working to isolate eventlet code within<br>
Keystone<br>
and bringing in the current implementation from Oslo-incubator would go<br>
against that work, as /oslo-incubator/openstack/<u></u>common/log.py imports<br>
/oslo-incubator/openstack/<u></u>common/local.py which has a dependency on<br>
eventlet<br>
<br>
(<a href="https://github.com/openstack/oslo-incubator/blob/master/openstack/common/local.py#L22" target="_blank">https://github.com/openstack/<u></u>oslo-incubator/blob/master/<u></u>openstack/common/local.py#L22</a>)<br>
and is used for storing references to contexts. I know there has been a<br>
couple of projects looking to not be dependent on eventlet and thought<br>
this<br>
might be a good topic for the mailing list, especially if these changes<br>
end<br>
up in Oslo-incubator.<br>
<br>
After discussion with a couple of the Keystone members, one option is to<br>
tweak local.py to check if eventlet is even installed (similar to def<br>
_ensure_subprocess here:<br>
<br>
<a href="https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py#L11" target="_blank">https://github.com/openstack/<u></u>python-keystoneclient/blob/<u></u>master/keystoneclient/common/<u></u>cms.py#L11</a>)<br>
and if it isn't then try implementing a different WeakLocal store not<br>
using<br>
corolocal.local. Any other ideas on how to approach this are more than<br>
welcome. Thanks!<br>
<br>
<br>
<br>
Best Regards,<br>
<br>
Lance Bragstad<br>
Software Engineer - OpenStack<br>
Cloud Solutions and OpenStack Development<br>
T/L 553-5409, External <a href="tel:507-253-5409" value="+15072535409" target="_blank">507-253-5409</a><br>
<a href="mailto:ldbragst@us.ibm.com" target="_blank">ldbragst@us.ibm.com</a>, Bld 015-2/C118<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
<br>
--<br>
Davanum Srinivas :: <a href="http://davanum.wordpress.com" target="_blank">http://davanum.wordpress.com</a><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>