Open Stack

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