On Oct 10, 2014, at 6:13 AM, Ihar Hrachyshka <[email protected]> wrote:
> Signed PGP part
> On 09/10/14 21:29, Mike Bayer wrote:
> > So so far, everyone seems really positive and psyched about the
> > proposal.
> >
> > It looks like providing some options for how to use would be best,
> > that is provide decorators and context managers.
> >
> > Now the thing with the context manager, it can be as I stated:
> >
> > with sql.reader() as session:
> >
> > or we can even have that accept the “context”:
> >
> > with sql.reader(context) as session:
> >
> > The latter again avoids having to use thread locals.
> >
> > But can I get a feel for how comfortable we are with using thread
> > local storage to implement this feature? I had anticipated people
> > wouldn’t like it because it’s kind of a “global” object, even
> > though it will be hidden behind this facade (of course CONF is
> > global as is sys.modules, and I think it is fine). If I just
> > use a tlocal, this whole thing is pretty simple.
>
> Won't the approach conflict with eventlet consumers that for some
> reason do not patch thread module, or do not patch it early enough? I
> guess in that case we may end up with mixed contexts.
I’ve been asking a lot about “hey are people cool with thread locals?” and have
been waiting for what the concerns are.
Since I wrote that email I’ve shifted, and I’ve been considering only:
@sql.reader
def my_api_method(context, …):
context.session
def my_api_method(context, …):
with sql.using_reader(context) as session:
session , context.session
because in fact, if you *want* to use a thread local context, you can,
explicitly with the above:
GLOBAL_CONTEXT = threading.local()
def my_api_method(…):
with sql.using_reader(GLOBAL_CONTEXT) as session:
session
I like that one the best. But again, Keystone folks would need to accept this
explicitness.
The challenge on my end is not technical in any way. It’s getting every
project to agree on a single approach and not getting bogged down with
idealistics (like, “let’s build a dependency injection framework!”). Because
this “everyone does it their own way” thing is crazy and has to stop.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
