Move to GreenThreadPoolExecutor

python3.7 and eventlet cause the `future.ThreadPoolExecutor` to hang
indefinitely. Moving to `futurist.GreenThreadPoolExecutor` allows the
`designate-worker` process to use native eventlet greenthreads, which bypasses
the hanging issue.

Closes-Bug: #1782647

Related-Bug: https://bugs.python.org/issue34173
Related-Bug: eventlet/eventlet#508

Change-Id: I36c79ca72635d81cfcc8d3cc87b1bc5e0657d9e8
Signed-off-by: Graham Hayes <gr@ham.ie>
This commit is contained in:
Graham Hayes 2018-07-26 20:57:10 +01:00
parent 8c17476203
commit 72e4e13d8e
No known key found for this signature in database
GPG Key ID: 1B263DC59F4AEFD5
4 changed files with 15 additions and 3 deletions

View File

@ -15,7 +15,7 @@
# under the License.
import time
from concurrent import futures
import futurist
from oslo_log import log as logging
from oslo_config import cfg
@ -32,7 +32,10 @@ def default_executor():
except Exception:
pass
return futures.ThreadPoolExecutor(thread_count)
# TODO(mugsie): if (when) we move away from eventlet this may have to
# revert back to ThreadPoolExecutor - this is changing due to
# https://bugs.launchpad.net/bugs/1782647 (eventlet + py37 issues)
return futurist.GreenThreadPoolExecutor(thread_count)
class Executor(object):

View File

@ -36,7 +36,7 @@ flake8==2.5.5
Flask==0.10
funcparserlib==0.3.6
future==0.16.0
futurist==1.6.0
futurist==1.2.0
gitdb2==2.0.3
GitPython==2.1.8
greenlet==0.4.10

View File

@ -0,0 +1,8 @@
---
other:
- |
To allow for python3.7 support, the `designate-worker` service was changed
from a `ThreadPoolExecutor` to a `GreenThreadPoolExecutor`. This should
no impact for most deployments, but in some cases it may cause performance
degredation. In these cases, tuning `[service:worker].workers` and
`[service:worker].threads` alleviate the issues.

View File

@ -48,3 +48,4 @@ tooz>=1.58.0 # Apache-2.0
debtcollector>=1.2.0 # Apache-2.0
os-win>=3.0.0 # Apache-2.0
monasca-statsd>=1.1.0 # Apache-2.0
futurist>=1.2.0 # Apache-2.0