Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread gordon chung
makes sense to me. thanks for concise update and tracking this. On 10/02/2016 7:59 AM, Davanum Srinivas wrote: > +1 from me > > On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote: >> On 02/10/2016 07:33 AM, Sean Dague wrote: >>> >>> The largeops tests at this point are mostly

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread David Moreau Simard
Lots of questions, I'm sorry. Are you planning to drop them indefinitely or is it temporary ? Is it to help alleviate the gate from it's current misery ? Why were these tests introduced in the first place ? To find issues or bottenecks relative to scale or amount of operations ? Was it a request

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Ghe Rivero
+1, although I would like to keep them to find scale bottlenecks. Maybe when the new infra-cloud is up (we'll have full control over it, includind hw access), we can pin these tests just to it. Ghe Rivero Quoting Sean Dague (2016-02-10 13:33:44) > The largeops tests at this point are mostly

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Sean Dague
On 02/10/2016 08:42 AM, David Moreau Simard wrote: > Lots of questions, I'm sorry. > > Are you planning to drop them indefinitely or is it temporary ? Is it to > help alleviate the gate from it's current misery ? > > Why were these tests introduced in the first place ? To find issues or >

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Flavio Percoco
On 10/02/16 07:33 -0500, Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Ihar Hrachyshka
Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were very

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Clint Byrum
Excerpts from Sean Dague's message of 2016-02-10 04:33:44 -0800: > The largeops tests at this point are mostly finding out that some of our > new cloud providers are slow - http://tinyurl.com/j5u4nf5 > > This is fundamentally a performance test, with timings having been tuned > to pass 98% of the

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Tim Bell
On 10/02/16 18:48, "Clint Byrum" wrote: >Excerpts from Sean Dague's message of 2016-02-10 04:33:44 -0800: >> The largeops tests at this point are mostly finding out that some of our >> new cloud providers are slow - http://tinyurl.com/j5u4nf5 >> >> This is fundamentally a

[openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Sean Dague
The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were very predictable in performance. We're now

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Jay Pipes
On 02/10/2016 07:33 AM, Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Davanum Srinivas
+1 from me On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote: > On 02/10/2016 07:33 AM, Sean Dague wrote: >> >> The largeops tests at this point are mostly finding out that some of our >> new cloud providers are slow - http://tinyurl.com/j5u4nf5 >> >> This is fundamentally a