+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 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 running on 4 clouds, and the variance between > them all, and between every run on each can be as much as a factor of 2. > > We could just bump all the timeouts again, but that's basically the same > thing as dropping them. > > These tests are not instrumented in a way that any real solution can be > addressed in most cases. Tests without a path forward, that are failing > good patches a lot, are very much the kind of thing we should remove > from the system. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > 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
