Comment 18 for bug 1282089

   > 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.

Right, i missed this one thanks, FWIW all happen here https://github.com/kennethreitz/requests/blob/v2.2.1/requests/packages/urllib3/poolmanager.py#L97, but it doesn't actually just create a new connection but a new pool for each end point, so my idea of EndPointSession to manage a connection pool per endpoint is already build-in in requests, which is pretty cool IMHO, so we can actually share a requests.Session between endpoints and users too (as far as i can tell), which is great, which beg the question again why we need more than one requests.Session in our case !?

  > 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.

I don't see how it's Horizon responsibility to tell the keystone client how to connect to the server, and FWIW i also don't agree with the fact that keystoneclient.session.Session accept a requests.Session argument, specially if this class is meant to be a high level class, you can't expect someone to add requests as dependency to their project if they want to set that argument and indirect dependencies are really not a good idea.

So i still think that connection pool are one of the best feature that python-requests offer and we should take advantage of it, not indirectly but as a builtin default option in keystoneclient (i don't know if it should be an option or no i.e. why someone will not want connection pool !?) .

Cheers,