[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
--
Thanks,
Matt
More information about the OpenStack-dev
mailing list