[openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full?

Matt Riedemann mriedemos at gmail.com
Sat Sep 29 20:35:28 UTC 2018

Nova, cinder and tempest run the nova-multiattach job in their check and 
gate queues. The job was added in Queens and was a specific job because 
we had to change the ubuntu cloud archive we used in Queens to get 
multiattach working. Since Rocky, devstack defaults to a version of the 
UCA that works for multiattach, so there isn't really anything 
preventing us from running the tempest multiattach tests in the 
integrated gate. The job tries to be as minimal as possible by only 
running tempest.api.compute.* tests, but it still means spinning up a 
new node and devstack for testing.

Given the state of the gate recently, I'm thinking it would be good if 
we dropped the nova-multiattach job in Stein and just enable the 
multiattach tests in one of the other integrated gate jobs. I initially 
was just going to enable it in the nova-next job, but we don't run that 
on cinder or tempest changes. I'm not sure if tempest-full is a good 
place for this though since that job already runs a lot of tests and has 
been timing out a lot lately [1][2].

The tempest-slow job is another option, but cinder doesn't currently run 
that job (it probably should since it runs volume-related tests, 
including the only tempest tests that use encrypted volumes).

Are there other ideas/options for enabling multiattach in another job 
that nova/cinder/tempest already use so we can drop the now mostly 
redundant nova-multiattach job?

[1] http://status.openstack.org/elastic-recheck/#1686542
[2] http://status.openstack.org/elastic-recheck/#1783405




More information about the OpenStack-dev mailing list