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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
