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.


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.


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

Reply via email to