Some projects are already running tox only.<div>I think there is no particular technical reason for which we're keeping both of them, if not that some developers (like me) are very stubborn and obstinate.</div><div>Up to a few months ago, run_tests.sh had some reason for existing because of the plugin specific unit tests, which are now all in the main test set (and that's where the memory usage bomb exploded).</div>
<div><br></div><div>We can have a discussion on removing run_tests.sh, and I have no major objection.</div><div><br></div><div><br><br><div class="gmail_quote">On 5 November 2012 08:58, Zhongyue Luo <span dir="ltr"><<a href="mailto:zhongyue.luo@gmail.com" target="_blank">zhongyue.luo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is kind of off topic but I was wondering why there are two different methods of testing? run_tests and tox<br><br>
Maybe I'm missing something but can't we just get rid of run_tests and use only tox?<br><div class="gmail_extra"><div><div class="h5">
<br><br><div class="gmail_quote">On Mon, Nov 5, 2012 at 3:05 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
<br>
On 11/05/2012 07:56 AM, Gary Kotton wrote:<br>
> On 11/04/2012 10:48 PM, Monty Taylor wrote:<br>
>><br>
>> On 11/04/2012 03:26 PM, Gary Kotton wrote:<br>
>>> On 10/24/2012 03:24 PM, Gary Kotton wrote:<br>
>>>> On 10/24/2012 12:20 AM, Monty Taylor wrote:<br>
>>>>> I believe that we can address this for both run_tests and tox with<br>
>>>>> some<br>
>>>>> of the testtools/fixtures stuff clark has been playing with. We'll<br>
>>>>> poke<br>
>>>>> at it tomorrow (he's out for the day) and see if we can get an<br>
>>>>> approach<br>
>>>>> that would make everyone happy.<br>
>>> I tried playing around with the flags in the tox.ini file. There are<br>
>>> options to run this in multiple processes. There are two flags that are<br>
>>> of interest:<br>
>>><br>
>>> 1. NOSE_PROCESS_RESTARTWORKER: - This is documented as follows:<br>
>>> "--process-restartworker<br>
>>> If set, will restart each worker process<br>
>>> once their<br>
>>> tests are done, this helps control memory leaks<br>
>>> from<br>
>>> killing the system.<br>
>>> [NOSE_PROCESS_RESTARTWORKER]"<br>
>>> 2. NOSE_PROCESSES: - This is documented as follows:<br>
>>> "--processes=NUM Spread test run among this many processes. Set a<br>
>>> number equal to the number of processors or<br>
>>> cores in<br>
>>> your machine for best results.<br>
>>> [NOSE_PROCESSES]"<br>
>> So - we're moving towards using testr as the test runner _instead_ of<br>
>> nose. There are several reasons for this, but one of them is better<br>
>> support for parallelism.<br>
>><br>
>> clarkb has been working on this for quantum - you might want to sync up<br>
>> with him if you're interested in helping out.<br>
><br>
> Thanks. I have been in touch with Clark. If I understand correctly when<br>
> he ran parallel tests this did not reduce the amount of memory consumed.<br>
> This was the reason I tried to set the above flags. I was hoping for a<br>
> magic bullet.<br>
<br>
</div></div>AH - gotcha. Yeah, magic bullet would be nice.<br>
<div><div><br>
>>> The problem that I have is that when the first variable is set nothing<br>
>>> is done, this is really dependent on the second. The problem when<br>
>>> setting the second is that I get the following exception:<br>
>>><br>
>>> garyk@linus:~/quantum$ tox<br>
>>> GLOB sdist-make: /home/garyk/quantum/setup.py<br>
>>> py26 create: /home/garyk/quantum/.tox/py26<br>
>>> ERROR: InterpreterNotFound: python2.6<br>
>>> py27 sdist-reinst: /home/garyk/quantum/.tox/dist/quantum-2013.1.zip<br>
>>> py27 runtests: commands[0]<br>
>>><br>
>>> /home/garyk/quantum/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/ext/declarative.py:1343:<br>
>>><br>
>>> SAWarning: The classname 'NetworkBinding' is already in the registry of<br>
>>> this declarative base, mapped to<class<br>
>>> 'quantum.plugins.openvswitch.ovs_models_v2.NetworkBinding'><br>
>>> _as_declarative(cls, classname, cls.__dict__)<br>
>>><br>
>>> Traceback (most recent call last):<br>
>>> File ".tox/py27/bin/nosetests", line 9, in<module><br>
>>> load_entry_point('nose==1.2.1', 'console_scripts', 'nosetests')()<br>
>>> File<br>
>>> "/home/garyk/quantum/.tox/py27/local/lib/python2.7/site-packages/nose/core.py",<br>
>>><br>
>>> line 118, in __init__<br>
>>> **extra_args)<br>
>>> File "/usr/lib/python2.7/unittest/main.py", line 95, in __init__<br>
>>> self.runTests()<br>
>>> File<br>
>>> "/home/garyk/quantum/.tox/py27/local/lib/python2.7/site-packages/nose/core.py",<br>
>>><br>
>>> line 197, in runTests<br>
>>> result = self.testRunner.run(self.test)<br>
>>> File<br>
>>> "/home/garyk/quantum/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/multiprocess.py",<br>
>>><br>
>>> line 357, in run<br>
>>> testQueue = Queue()<br>
>>> File "/usr/lib/python2.7/multiprocessing/managers.py", line 667,<br>
>>> in temp<br>
>>> token, exp = self._create(typeid, *args, **kwds)<br>
>>> File "/usr/lib/python2.7/multiprocessing/managers.py", line 565, in<br>
>>> _create<br>
>>> conn = self._Client(self._address, authkey=self._authkey)<br>
>>> File "/usr/lib/python2.7/multiprocessing/connection.py", line 175, in<br>
>>> Client<br>
>>> answer_challenge(c, authkey)<br>
>>> File "/usr/lib/python2.7/multiprocessing/connection.py", line 413, in<br>
>>> answer_challenge<br>
>>> message = connection.recv_bytes(256) # reject large message<br>
>>> IOError: [Errno 11] Resource temporarily unavailable<br>
>>><br>
>>> Has anyone ever encountered something like this.<br>
>>> Thanks<br>
>>> Gary<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><b>Intel SSG/SSD/SOTC/PRC/CITT</b></div>
<div>880 Zixing Road, Zizhu Science Park, Minhang District, Shanghai, 200241,
China<br></div>
<div><a href="tel:%2B862161166500" value="+862161166500" target="_blank">+862161166500</a></div><br>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>