On Sat, Sep 29, 2018 at 10:35 PM, Matt Riedemann <mriede...@gmail.com>
wrote:
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.
+1
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).
If the multiattach test qualifies as a slow test then I'm in favor of
adding it to the tempest-slow and not lengthening the tempest-full
further.
gibi
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev