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

2018-10-01 Thread Jay S Bryant



On 10/1/2018 10:28 AM, Matt Riedemann wrote:

On 10/1/2018 8:37 AM, Ghanshyam Mann wrote:
+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


Sean and I are working on getting those changes merged.  So, that will 
be good.
Actually it will be enabled in both tempest-full and tempest-slow, 
because there is also a multiattach test marked as 'slow': 
TestMultiAttachVolumeSwap.


I'll push patches today.


Thank you!  I think this is the right way to go.

__
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


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

2018-10-01 Thread Matt Riedemann

On 10/1/2018 8:37 AM, Ghanshyam Mann wrote:

+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


Actually it will be enabled in both tempest-full and tempest-slow, 
because there is also a multiattach test marked as 'slow': 
TestMultiAttachVolumeSwap.


I'll push patches today.

--

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


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

2018-10-01 Thread Ghanshyam Mann
  On Mon, 01 Oct 2018 21:22:46 +0900 Erlon Cruz  wrote 
 
 > 
 > 
 > Em seg, 1 de out de 2018 às 05:26, Balázs Gibizer 
 >  escreveu:
 > 
 >  
 >  On Sat, Sep 29, 2018 at 10:35 PM, Matt Riedemann  
 >  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-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
 >   __
 > 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


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

2018-10-01 Thread Erlon Cruz
Em seg, 1 de out de 2018 às 05:26, Balázs Gibizer <
balazs.gibi...@ericsson.com> escreveu:

>
>
> On Sat, Sep 29, 2018 at 10:35 PM, Matt Riedemann 
> 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 .


> 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
>
__
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


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

2018-10-01 Thread Balázs Gibizer



On Sat, Sep 29, 2018 at 10:35 PM, Matt Riedemann  
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


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

2018-09-29 Thread Matt Riedemann
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

__
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