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>

designate/worker/processing.py

@@ -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):

lower-constraints.txt

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

releasenotes/notes/worker-executor-84d983c92dd13b49.yaml

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

requirements.txt

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