Comment 21 for bug 1282089

From what i can see there is no reason that horizon would need more that one requests.Session(). In fact i think that horizon would probably be the largest winner from sharing a session object as the authentication information is added per request rather than by the requests.Session object.

The main problem is that the keystoneclient.Session object is not necessarily well named, it is analogous to the requests.Session object and that is where the name came from but it was designed in such a way that one keystoneclient.Session object is linked to one keystoneclient auth mechanism. Essentially the same as if you added a cookie or an auth object to a requests.Session then everything passing through that requests.Session object would contain that cookie, everything passing through that keystoneclient.Session object contains that keystone token.

This pattern we are planning to push out to other clients such that one session object is established and used by the keystoneclient, novaclient, glanceclient etc - so you handle auth once. This will be very useful to people who are spanning multiple clients in there work.

This is the reverse of the horizon case where you largely have multiple authentications that you want to send down the same connection. This is why the ability to pass in a requests.Session object was created. For horizon you will still need to have one keystoneclient.Session per authentication but if you create a single requests.Session object and pass that around you will get connection pooling that does not interfere with the authentication.

As for handling a requests.Session object - i see no problem with people being expected to do that. The primary use case where a keystoneclient.Session object is created and then shared amongst clients will mean that all the clients get connection pooling for free and the requests.Session object is managed for them. In the case you want to work outside of this pattern as Horizon does you do a little extra work to get that benefit. The dependency on request is already satisifed by all clients and i fall back to 'make the common case simple and the unusual case achievable'.

Note: that i have been experimenting with ways to handle multiple authentication plugins using the one keystoneclient.Session so that the likes of horizon/heat could only ever create one keystoneclient.Session object and many Auth Plugins. This will be dependant on the process of getting it into other clients and how much it is requested.