Updates inline. On 2/5/2019 8:35 AM, Matt Riedemann wrote:
I'd like to propose some changes primarily to the CI jobs that run on nova changes, but also impact cinder and tempest.
1. Drop the nova-multiattach job and move test coverage to other jobs
This is actually an old thread [1] and I had started the work but got hung up on a bug that was teased out of one of the tests when running in the multi-node tempest-slow job [2]. For now I've added a conditional skip on that test if running in a multi-node job. The open changes are here [3].
Done: https://review.openstack.org/#/q/status:merged+topic:drop-multiattach-job
2. Only run compute.api and scenario tests in nova-next job and run under python3 only
The nova-next job is a place to test new or advanced nova features like placement and cells v2 when those were still optional in Newton. It currently runs with a few changes from the normal tempest-full job:
* configures service user tokens * configures nova console proxy to use TLS * disables the resource provider association refresh interval * it runs the post_test_hook which runs some commands like archive_delete_rows, purge, and looks for leaked resource allocations [4]
Like tempest-full, it runs the non-slow tempest API tests concurrently and then the scenario tests serially. I'm proposing that we:
a) change that job to only run tempest compute API tests and scenario tests to cut down on the number of tests to run; since the job is really only about testing nova features, we don't need to spend time running glance/keystone/cinder/neutron tests which don't touch nova.
Proposed: https://review.openstack.org/#/c/636459/ (+2 from Stephen)
b) run it with python3 [5] which is the direction all jobs are moving anyway
Done: https://review.openstack.org/#/c/634739/
3. Drop the integrated-gate (py2) template jobs (from nova)
Nova currently runs with both the integrated-gate and integrated-gate-py3 templates, which adds a set of tempest-full and grenade jobs each to the check and gate pipelines. I don't think we need to be gating on both py2 and py3 at this point when it comes to tempest/grenade changes. Tempest changes are still gating on both so we have coverage there against breaking changes, but I think anything that's py2 specific would be caught in unit and functional tests (which we're running on both py27 and py3*).
Proposed: https://review.openstack.org/#/c/634949/ (+2 from Stephen) -- Thanks, Matt