It seems that the problem in keystone has the same nature as the one in neutron. A wsgi server is started in a green thread from the same green pool that as passed to the server as a custom pool which is used to handle client requests [1],[2]. So when we try to stop a server, waitall() is eventually called for all green threads in that pool, including the thread which issued that call. And that results in an exception that is observed in logs.
There is a working fix for neutron [3], which is currently under review, that simply uses different pools for spawning
a wsgi server and for its internal usage. Comments are highly appreciated.
It seems that the problem in keystone has the same nature as the one in neutron. A wsgi server is started in a green thread from the same green pool that as passed to the server as a custom pool which is used to handle client requests [1],[2]. So when we try to stop a server, waitall() is eventually called for all green threads in that pool, including the thread which issued that call. And that results in an exception that is observed in logs.
There is a working fix for neutron [3], which is currently under review, that simply uses different pools for spawning
a wsgi server and for its internal usage. Comments are highly appreciated.
[1] https:/ /github. com/openstack/ keystone/ blob/b72fb2feeb 066ec09ee4b6c6b 6cc680e8a8f37b7 /keystone/ common/ environment/ eventlet_ server. py#L138 /github. com/openstack/ keystone/ blob/b72fb2feeb 066ec09ee4b6c6b 6cc680e8a8f37b7 /keystone/ common/ environment/ eventlet_ server. py#L178 /review. openstack. org/#/c/ 157320
[2] https:/
[3] https:/