Comment 15 for bug 1282089

I'm happy to debate the scope of the session object, i know there has been a number of people raising concerns about the intermingling of the transport layer work with the user session management. I'm not adverse to splitting them up but i just haven't heard anything that would make this advantageous.

I'm not sure what your endpoint session will do in this case. when you use requests connection pools (requests.Session) you don't need to allocate one pool per endpoint. if i do:

   s = requests.Session()
   s.get('http://google.com')
   s.get('http://yahoo.com')
   s.get('http://openstack.org')

the connection pool object is smart enough to know that it can't send all that down the same connection and will open a new connection for it.

From what i can see all that EndPointSession above would be doing is making us do the management of host -> connection pool object.

Note that the keystoneclient.session.Session object takes a request.Session as a parameter, so if you want to use connection pooling in horizon all you need to do is create a request.Session() and pass that into keystoneclient. If the change over to using session directly causes too many problems (for now - we'll hopefully tackle this properly in Juno) then i can easily change that to have client.Client accept a requests_session parameter?