Py37 job always reports timeout error recently.
Please see [1] [2] [3].
At first it was suspected that the error was reported
because of the patch [4].
Therefore, Feng Shaohe's patch [5] revoked the merge,
and at this time, disappeared at py37 timeout.
But in fact, this problem is just hidden.
After removing this setting, the job of py37
is actually running on the environment of python 3.6
(community CI default version is 3.6), please see [6]
for detailed reasons.
Therefore, this patch exposes the hidden py37 timeout problem,
and at the same time, found method test_apply_patch_fpga_arq_monitor_job
, think it is the reason of the timeout. The reason I can find
this method is based on the the troubleshooting of tox -epy37 log.
After commenting out this method, I found that tox -epy37 can run
normally and there is no longer a timeout problem.
If you want to test, please ensure that you have a local
python3.7 environment, not 3.6, and execute rm .tox / -rf.
Then execute tox -epy37.
Therefore, the best way is to comment out this method and
restore py37 job at the same time.
If a friend discovers further reasons and solution, this method
can be restored, please refer to [7].
What went wrong in this method?
It is because in the deep call of this method, ThreadWork of
the thread pool will be used, which under Python3.7 will block
the execution of unit tests. For specific reasons, please see
[8] [9].
Reference:
[1]. https://review.opendev.org/#/c/702578/
[2]. https://review.opendev.org/#/c/703049/
[3]. https://review.opendev.org/#/c/703253/
[4]. https://review.opendev.org/#/c/696397/
[5]. https://review.opendev.org/#/c/706911/
[6]. http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2020-02-12.log.html#t2020-02-12T16:46:18
[7]. deed9c822e
[8]. https://review.opendev.org/#/c/707045/5//COMMIT_MSG
[9]. c61dd8c376/cyborg/objects/extarq/ext_arq_job.py (L41)
Change-Id: I09db889fe665c6246ec9503af92c909e7d0da24f
08af601271