Comment 1 for bug 1780164

We have also noticed this problem.
We did an strace on horizon and found that the connections made by horizon to keystone were not getting closed.

Digging deeper, we found 2 very similar commits that fix connection closure issues related to keystone.

https://github.com/openstack/python-keystoneclient/commit/8fcacdc7c74f5ac68e8e55ea8c15918c452411fe

and

https://github.com/openstack/keystoneauth/commit/dbcbf414ac8423e97d77d0bda8157be5350530f0

I think that the commit in keystoneauth is incomplete, it's missing the destination of the move of the _FakeRequestSession class and so it's just a removal.

In Newton, horizon is using keystoneclient to get keystone sessions and we don't see the connection leaks.
Somewhere between Newton and Queens, horizon switched to keystoneauth and lost the _FakeRequestSession hack and so we are now seeing a regression where horizon is leaking connections again.

I am attaching a patch that we are currently testing, it re-introduces the _FakeRequestSession class into keystoneauth.
The patch is a little naive, I don't know what to do with the instance attribute "adapters" of _FakeRequestSession, I just set it to an empty list because it is being referenced by code elsewhere. It seems to be working for now.