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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to