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

Ghanshyam Mann gmann at ghanshyammann.com
Mon Oct 1 13:37:49 UTC 2018


 ---- On Mon, 01 Oct 2018 21:22:46 +0900 Erlon Cruz <sombrafam at gmail.com> wrote ---- 
 > 
 > 
 > Em seg, 1 de out de 2018 às 05:26, Balázs Gibizer <balazs.gibizer at ericsson.com> escreveu:
 > 
 >  
 >  On Sat, Sep 29, 2018 at 10:35 PM, Matt Riedemann <mriedemos at 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.
 >  
 > +1 On having this on tempest-slow and add this to Cinder, provided that it would also cover encryption .

+1 on adding multiattach on integrated job. It is always good to cover more features in integrate-gate instead of separate jobs. These tests does not take much time, it should be ok to add in tempest-full [1]. We should make only really slow test as 'slow' otherwise it should be fine to run in tempest-full.

I thought adding tempest-slow on cinder was merged but it is not[2]

[1]  http://logs.openstack.org/80/606880/2/check/nova-multiattach/7f8681e/job-output.txt.gz#_2018-10-01_10_12_55_482653
[2] https://review.openstack.org/#/c/591354/2

-gmann

 >   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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 > 





More information about the OpenStack-dev mailing list