Open Stack

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 ;)

    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> 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>
> 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
>
> _______________________________________________
> 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/8ac13533/attachment.html>