Open Stack

On 08/02/2012 10:52 AM, Stef Telford wrote:
> Hey Adam, Everyone,
>    Thanks for the quick response, and the link on DI. I am not really 
> a fan of DI but, if that's the way the cool kids are going, so be it ;)

What is it with you guys calling me names?  I never was, nor ever will 
be, one of the cool kids!

Heh.

DI can be abused, and most of the implementations I've seen have been 
horrific, especially in Java.  With Python,  we can have a much lighter 
touch,  and keep things Pythonic.  I'm working on a clear example that I 
will post shortly.


The identity driver gets called from the routes established at the WSGI 
level, including what information to pass to the function.  Probably the 
easiest place to see things is in

keystone/service.py:  the class AdminRouter(wsgi.ComposingRouter):  
registers the routes in its constructor:

  mapper.connect('/tokens',
                        controller=auth_controller,
                        action='authenticate',
                        conditions=dict(method=['POST']))

so this is going to find a variable named auth_controller and call the 
authenticate method on it, passing in a dictionary.  This resolves to 
the      TokenController (in the same file) and the authenticate method, 
at around line 263.  context is the first parameter there.

Many of the routes you would be interested in are defined in the 
AdminRouter inside keysteon/identity/core.py and have the context 
parameter in the first position.





>
>     Realistically, all I am wondering is, how does the identity driver 
> get at all the information from the wsgi or Driver ? Say, for example, 
> I wanted to know/grab the openstack.context (which has the 'is_admin' 
> flag inside it). Since it's simply a dict, I was thinking of jst 
> passing in any values via the manager if they existed. However, that's 
> changing the core keystone manager, only putting in the 
> openstack.context (not all the context values for wsgi) and I assume 
> few people would ~need~ this.
>
>     Still coming upto speed on how keystone's design works, so sorry 
> if this doesn't make much sense ;)
>     Regards
>     S.
>
> On Wed, Aug 1, 2012 at 2:18 PM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     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
>     <mailto:stelford at internap.com>>
>     To: openstack-dev at lists.openstack.org
>     <mailto: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
>     <mailto: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
>     <mailto: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/20120802/c8f98cac/attachment.html>