Open Stack

On 18 Jul 2015 6:29 am, michael mccune <msm at redhat.com> wrote:
>
> On 07/16/2015 04:31 PM, michael mccune wrote: 
> > i will also likely be rewriting the spec to encompass these changes if i 
> > can get them working locally. 
>
> just wanted to follow up before i rewrite the spec. 
>
> i think the most sensible approach at this point is to store an auth 
> plugin object in our context. this will alleviate some of our reliance 
> on the username/tenant_id/etc. authentication values that we currently 
> use. this object will also be used in conjunction with the session cache 
> to produce clients. 
>
> the session cache will be removed from the context and instead become a 
> singleton type object in the sahara.service.sessions module. the cache 
> will contain several specific functions for creating session objects for 
> our different needs. for example, nova session will need to pass the 
> specific nova certificate to the session. for non-specific needs the 
> session object can be shared between several clients. 
>
> the clients themselves will use a combination of auth plugin object and 
> session object for creation. in this manner we can associate different 
> authentications with the sessions as needed and still share the 
> connection pooling and caching that occurs in the session object. this 
> will also allow us to continue to create admin clients as needed, we can 
> either pass an admin authentication object to the client or set the 
> context to have an admin authenticated plugin object. 
>
> there are still a few questions to be answered about trust scoping, but 
> i think they will fit in this model. i would still be curious to hear 
> any thoughts about this approach, but i will continue to test it and 
> work towards rewriting the spec. 
>
> regards, 
> mike 
>
So I'm not familiar with how Sahara handles contexts however from a theoretical stand point anything that is defined in config should be able to be cached globally. So service specific sessions, and admin auth. The context typically would contain things relevant to this request, however for convenience it might be worth having a pointer from context to the global.

You then create clients then with the combination of session+auth. You don't need/want to attach the auth plugin to the session here as that makes it difficult to reuse.

When using sessions like this client creation is cheap (no requests are made) so there's no reason to hang on to the client objects themselves.

I'm not sure if that helped at all but catch me on IRC and I'll help out with what I can.

Jamie

> __________________________________________________________________________ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev