<p dir="ltr"><br>
On Feb 26, 2014 7:37 PM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
><br>
><br>
><br>
> On 2/25/2014 7:46 PM, Matt Riedemann wrote:<br>
>><br>
>><br>
>><br>
>> On 2/12/2014 1:57 PM, Matthew Treinish wrote:<br>
>>><br>
>>> On Wed, Feb 12, 2014 at 11:32:39AM -0700, Matt Riedemann wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On 1/17/2014 8:34 AM, Matthew Treinish wrote:<br>
>>>>><br>
>>>>> On Fri, Jan 17, 2014 at 08:32:19AM -0500, David Kranz wrote:<br>
>>>>>><br>
>>>>>> On 01/16/2014 10:56 PM, Matthew Treinish wrote:<br>
>>>>>>><br>
>>>>>>> Hi everyone,<br>
>>>>>>><br>
>>>>>>> With some recent changes made to Tempest compatibility with<br>
>>>>>>> nosetests is going<br>
>>>>>>> away. We've started using newer features that nose just doesn't<br>
>>>>>>> support. One<br>
>>>>>>> example of this is that we've started using testscenarios and<br>
>>>>>>> we're planning to<br>
>>>>>>> do this in more places moving forward.<br>
>>>>>>><br>
>>>>>>> So at Icehouse-3 I'm planning to push the patch out to remove<br>
>>>>>>> nosetests from the<br>
>>>>>>> requirements list and all the workarounds and references to nose<br>
>>>>>>> will be pulled<br>
>>>>>>> out of the tree. Tempest will also start raising an unsupported<br>
>>>>>>> exception when<br>
>>>>>>> you try to run it with nose so that there isn't any confusion on<br>
>>>>>>> this moving<br>
>>>>>>> forward. We talked about doing this at summit briefly and I've<br>
>>>>>>> brought it up a<br>
>>>>>>> couple of times before, but I believe it is time to do this now. I<br>
>>>>>>> feel for<br>
>>>>>>> tempest to move forward we need to do this now so that there isn't<br>
>>>>>>> any ambiguity<br>
>>>>>>> as we add even more features and new types of testing.<br>
>>>>>><br>
>>>>>> I'm with you up to here.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Now, this will have implications for people running tempest with<br>
>>>>>>> python 2.6<br>
>>>>>>> since up until now we've set nosetests. There is a workaround for<br>
>>>>>>> getting<br>
>>>>>>> tempest to run with python 2.6 and testr see:<br>
>>>>>>><br>
>>>>>>> <a href="https://review.openstack.org/#/c/59007/1/README.rst">https://review.openstack.org/#/c/59007/1/README.rst</a><br>
>>>>>>><br>
>>>>>>> but essentially this means that when nose is marked as unsupported<br>
>>>>>>> on tempest<br>
>>>>>>> python 2.6 will also be unsupported by Tempest. (which honestly it<br>
>>>>>>> basically has<br>
>>>>>>> been for while now just we've gone without making it official)<br>
>>>>>><br>
>>>>>> The way we handle different runners/os can be categorized as "tested<br>
>>>>>> in gate", "unsupported" (should work, possibly some hacks needed),<br>
>>>>>> and "hostile". At present, both nose and py2.6 I would say are in<br>
>>>>>> the unsupported category. The title of this message and the content<br>
>>>>>> up to here says we are moving nose to the hostile category. With<br>
>>>>>> only 2 months to feature freeze I see no justification in moving<br>
>>>>>> py2.6 to the hostile category. I don't see what new testing features<br>
>>>>>> scheduled for the next two months will be enabled by saying that<br>
>>>>>> tempest cannot and will not run on 2.6. It has been agreed I think<br>
>>>>>> by all projects that py2.6 will be dropped in J. It is OK that py2.6<br>
>>>>>> will require some hacks to work and if in the next few months it<br>
>>>>>> needs a few more then that is ok. If I am missing another connection<br>
>>>>>> between the py2.6 and nose issues, please explain.<br>
>>>>>><br>
>>>>><br>
>>>>> So honestly we're already at this point in tempest. Nose really just<br>
>>>>> doesn't<br>
>>>>> work with tempest, and we're adding more features to tempest, your<br>
>>>>> negative test<br>
>>>>> generator being one of them, that interfere further with nose. I've<br>
>>>>> seen several<br>
>>>><br>
>>>><br>
>>>> I disagree here, my team is running Tempest API, CLI and scenario<br>
>>>> tests every day with nose on RHEL 6 with minimal issues.  I had to<br>
>>>> workaround the negative test discovery by simply sed'ing that out of<br>
>>>> the tests before running it, but that's acceptable to me until we<br>
>>>> can start testing on RHEL 7.  Otherwise I'm completely OK with<br>
>>>> saying py26 isn't really supported and isn't used in the gate, and<br>
>>>> it's a buyer beware situation to make it work, which includes<br>
>>>> pushing up trivial patches to make it work (which I did a few of<br>
>>>> last week, and they were small syntax changes or usages of<br>
>>>> testtools).<br>
>>>><br>
>>>> I don't understand how the core projects can be running unit tests<br>
>>>> in the gate on py26 but our functional integration project is going<br>
>>>> to actively go out and make it harder to run Tempest with py26, that<br>
>>>> sucks.<br>
>>>><br>
>>>> If we really want to move the test project away from py26, let's<br>
>>>> make the concerted effort to get the core projects to move with it.<br>
>>><br>
>>><br>
>>> So as I said before the python 2.6 story for tempest remains the same<br>
>>> after this<br>
>>> change. The only thing that we'll be doing is actively preventing nose<br>
>>> from<br>
>>> working with tempest.<br>
>>><br>
>>>><br>
>>>> And FWIW, I tried the discover.py patch with unittest2 and<br>
>>>> testscenarios last week and either I botched it, it's not documented<br>
>>>> properly on how to apply it, or I screwed something up, but it<br>
>>>> didn't work for me, so I'm not convinced that's the workaround.<br>
>>>><br>
>>>> What's the other option for running Tempest on py26 (keeping RHEL 6<br>
>>>> in mind)?  Using tox with testr and pip?  I'm doing this all<br>
>>>> single-node.<br>
>>><br>
>>><br>
>>> Yes, that is what the discover patch is used to enable. By disabling<br>
>>> nose the<br>
>>> only path to run tempest with py2.6 is to use testr. (which is what it<br>
>>> always<br>
>>> should have been)<br>
>>><br>
>>> Attila confirmed it was working here:<br>
>>> <a href="http://fpaste.org/76651/32143139/">http://fpaste.org/76651/32143139/</a><br>
>>> in that example he applies 2 patches the second one is currently in<br>
>>> the gate for<br>
>>> tempest. (<a href="https://review.openstack.org/#/c/72388/">https://review.openstack.org/#/c/72388/</a> ) So all that needs<br>
>>> to be done<br>
>>> is to apply that discover patch:<br>
>>><br>
>>> <a href="https://code.google.com/p/unittest-ext/issues/detail?id=79">https://code.google.com/p/unittest-ext/issues/detail?id=79</a><br>
>>><br>
>>> (which I linked to before)<br>
>>><br>
>>> Then tempest should run more or less the same between 2.7 and 2.6.<br>
>>> (The only<br>
>>> difference I've seen is in how skips are handled)<br>
>>><br>
>>>><br>
>>>>> patches this cycle that attempted to introduce incorrect behavior<br>
>>>>> while trying<br>
>>>>> to fix compatibility with nose. That's why I think we need a clear<br>
>>>>> message on<br>
>>>>> this sooner than later. Which is why I'm proposing actively raising<br>
>>>>> an error<br>
>>>>> when things are run with nose upfront so there isn't any illusion<br>
>>>>> that things<br>
>>>>> are expected to work.<br>
>>>>><br>
>>>>> This doesn't necessarily mean we're moving python 2.6 to the hostile<br>
>>>>> category.<br>
>>>>> Nose support is independent of python 2.6 support. Py26 I would<br>
>>>>> still consider<br>
>>>>> to be unsupported, the issue is that the hack to make py26 work is<br>
>>>>> outside of<br>
>>>>> tempest. This is why we've recommended that people using python 2.6<br>
>>>>> run with<br>
>>>>> nose, which really is no longer an option. Attila's abandoned patch<br>
>>>>> that I<br>
>>>>> linked above documents points to this bug with a patch to discover<br>
>>>>> which is<br>
>>>>> need to get python 2.6 working with tempest and testr:<br>
>>>>><br>
>>>>> <a href="https://code.google.com/p/unittest-ext/issues/detail?id=79">https://code.google.com/p/unittest-ext/issues/detail?id=79</a><br>
>>><br>
>>><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> One question I had was is there an easy way to setup a config file to<br>
>> specify the test bucket and what can be excluded, like you can with<br>
>> nose.cfg and nose?  We used that for filtering out API tests that didn't<br>
>> work with the PowerVM driver in Nova but I'm not aware of something<br>
>> similar with testr.<br>
>><br>
><br>
> Another question I guess, and I know this is too late now, but the nosexcover package allowed us to get xunit xml results for the test runs and then jenkins has a nice way to process that xml and keep a history of failures and dig into the stack traces, how long the tests take, trends, etc.  I'm assuming there is nothing like that available with testr?<br>

><br>
><br>
> -- <br>
><br>
> Thanks,<br>
><br>
> Matt Riedemann<br>
><br>
><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
<p dir="ltr">There is a subunit to xunit converter bundled with python-subunit. subunit2xunit maybe? On a phone so hard to check.</p>
<p dir="ltr">Also fwiw using Jenkins to mangle that data doesn't scale well which is why we don't do it. This may or may not be a problem. In particular the xunit plugin has a global lock and jobs that use it can't finish until the previous job has had its xunit processed. This is terrible.</p>

<p dir="ltr">Clark</p>