Open Stack

> -----Original Message-----
> From: Victor Stinner [mailto:vstinner at redhat.com]
> Sent: Monday, May 16, 2016 7:20 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db
> 
> Hi,
> 
> Le 09/05/2016 16:38, Amrith Kumar a écrit :
> > So I'm able to run the py34 tests in about 10s if I run the dangling
> > mock detector with a depth of 0 or 1.
> 
> IMHO the strange mock detector code must be removed. It is very slow and
> I don't understand its purpose.

[amrith] It serves and has served a very useful purpose and that is to detect bad tests where code has (and we've had lots of trouble with this) established a Mock() but failed to delete it. Unfortunately, it is bad enough that Mock() is not thread specific (and the tests are multi-threaded) but even worse, if a mock persists later tests can go awfully wrong, or pass for no apparent reason.

I'd rather figure out why it is slower in Python3 because it may be indicative of something that may impact other parts of the code as well. We're having this whole discussion about Python performance and the Go language, I think it is not a good idea to delete code which is performing poorly because it is performing slowly.

> 
> The mock module has a nice stop_all() method, why not using it?
> https://docs.python.org/dev/library/unittest.mock.html#unittest.mock.patch
> .stopall
> 

[amrith] because stop_all isn't quite the same thing.

> The fixtures and oslotest modules also help to stop mocks.
> 
> (I don't know if the "mock detector" thing is related to the slow tests
> on Python 3.)

[amrith] It sure is slower in Python3.

> 
> Victor
> 
> __________________________________________________________________________
> 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