Open Stack

Can you provide a sense of the features you are looking to implement this way?

The Roles can always be requeried,  although I will admit that it is sub optimal.

Personally, I am not a fan of passing around the Context object the way that we do.  I would much prefer an inversion of control, where each component registers its dependencies, and the context plays the middleman in handing them out. 

http://wiki.python.org/moin/DependencyInjectionPattern

There are some thoughts on the link:

http://code.activestate.com/recipes/413268/


For our purposes, we need to only concern ourselves with Request and GLobally scoped objects,  though there is always the possibility of a session sneaking in there in the future (perhaps for paging functionality in LDAP deployments)





----- Original Message -----
From: "Stef Telford" <stelford at internap.com>
To: openstack-dev at lists.openstack.org
Sent: Wednesday, August 1, 2012 1:19:48 PM
Subject: [openstack-dev] [keystone] Accessing current Context from inside an	Identity driver ?


Hey Everyone, 
Recently, I have been digging in and around keystone, and there is a need for the current context to be made available to the identity driver rather than merely the manager. This is mostly so the identity driver can have the current roles for authee/user. I noticed in keystone/common/manager.py (where it ties everything together) that there is a note which says; 



def __getattr__(self, name): 
"""Forward calls to the underlying driver.""" 
# NOTE(termie): context is the first argument, we're going to strip 
# that for now, in the future we'll probably do some 
# logging and whatnot in this class 


My question is, what's the "approved" solution to passing over the context ? I could always stuff the context into the **kw or append it to the args but, seems rather .. sub-optimal. Is there any design hints/tips ? I don't fancy maintaining a set of patches against the main branch jst for our codebase, and would rather do something to benefit everyone. I think this may come up again in the future ;) 


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