On 07/17/2015 07:55 PM, Jamie Lennox wrote:
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
hi Jamie,
yes that does help, and i think we are on the same page in terms of the
implementation i'm exploring.
so, i have created a global object to hold the sessions we are using.
namely a generic session and then any specific sessions we might need
(based on using certs and what not).
the context only holds the auth info for the current user, i'm storing
the auth plugin that comes from the keystonemiddleware out of convenience.
when we create client objects we are using a session from the global
cache plus an auth plugin object from the context or an admin generated
auth plugin.
it seems to be working well so far, i have a few issues to sort out with
trusts and when to inject them in the process. but, i think this
methodology will work for us in general.
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
