We are facing the same issue on our internal NetApp CI while running Manila MySQL `test_walk_versions`.
I might misunderstanding the neutron fix [1], it does not fit very well on Manila walk tests: I implemented the same solution [2], and it took much longer time to finish the test. On my internal VM it didn't work, slowing down the execution.
I just wondered why the test walks do a snake and downgrade. During upgrade test, the snake option makes the downgrade tests. What if we ignore the reverse walk [3] ?
We are facing the same issue on our internal NetApp CI while running Manila MySQL `test_walk_ versions` .
I might misunderstanding the neutron fix [1], it does not fit very well on Manila walk tests: I implemented the same solution [2], and it took much longer time to finish the test. On my internal VM it didn't work, slowing down the execution.
I just wondered why the test walks do a snake and downgrade. During upgrade test, the snake option makes the downgrade tests. What if we ignore the reverse walk [3] ?
[1] https:/ /review. opendev. org/c/openstack /neutron/ +/770935 /review. opendev. org/c/openstack /manila/ +/852005 /github. com/openstack/ manila/ blob/master/ manila/ tests/db/ migrations/ alembic/ test_migration. py#L93- L98
[2] https:/
[3] https:/