Comment 11 for bug 1282089

I read again Jamie Lennox's article about Sessions:
http://www.jamielennox.net/blog/2014/02/24/client-session-objects/

As well as Python requests module doc:
http://docs.python-requests.org/en/latest/user/advanced/

FWIU, keystoneclient.session.Session and requests.Session objetcs are
not meant to be shared between different users. Instances of these
classes store information related to a single user (for instance a
user's token). Therefore, we shouldn't have one unique Session
instance shared amongst all users. However, it would make sense to
have a global connection pool inside Horizon. Looks like the
requests.adapters.HTTPAdapater would be a good candidate for such http
connections pool.

Well, I think that's also what was saying Dean Troyer there (Feb 19):
https://review.openstack.org/#/c/74720/

IMHO, keystoneclient.session.Session cannot be mapped on a user
session properly by Horizon, since Horizon doesn't know when a user's
session is terminated (unless he explicitly clicks on the logout
button), and can't "close" the session. Therefore, with Horizon, we
can at best use one keystoneclient.session.Session per request. And
this session should be closed (to release the connections used during
this session) without relying on the GC, which apparently isn't
efficient enough to avoid the current bug.

From the tests I've been doing, I think that most connections leakage
come from django_openstack_auth module. python-keystoneclient is used
in Horizon too. The api/keystone.py module will need to be fixed too.

I've started to implement a connections pool in django_openstack_auth,
but it looks that python-keystoneclient doesn't like when Clients are
instanciated with an unauthenticated Session object as argument ->
Further investigating.