Open Stack

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