[openstack-dev] [Fuel] py.test vs testrepository

Davanum Srinivas davanum at gmail.com
Tue Oct 6 22:02:11 UTC 2015


Sebastian,

I am really hoping that the items Monty listed below are enough. Also, if
you are interested, folks do use other things for running their tests
especially to find problems when testr hides some errors. Example, please
see:

https://davanum.wordpress.com/2015/01/13/quickly-running-a-single-openstack-nova-test/

Thanks,
Dims



On Tue, Oct 6, 2015 at 5:47 PM, Monty Taylor <mordred at inaugust.com> wrote:

> On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote:
>
>> I've already wrote in the review that caused this thread that I do not
>> want
>> to blindly follow rules for using one or another. We should always
>> consider
>> technical requirements. And I do not see a reason to leave py.test (and
>> nobody
>> show me such reason) and replace it with something else.
>>
>
> Hi!
>
> The reason is that testrepository is what OpenStack uses and as I
> understand it, Fuel wants to join the Big Tent.
>
> The use of testr is documented in the Project Testing Interface:
>
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/project-testing-interface.rst#n78
>
> There are many reasons for it, but in large part we are continually adding
> more and more tools to process subunit output across the board in the Gate.
> subunit2sql is an important one, as it will be feeding into expanded test
> result dashboards.
>
> We also have zuul features in the pipeline to be able to watch the subunit
> streams in real time to respond more quickly to issues in test runs.
>
> We also have standard job builders based around tox and testr. Having
> project divergence in this area is a non-starter when there are over 800
> repositories.
>
> In short, while I understand that this seems like an area where a project
> can do whatever it wants to, it really isn't. If it's causing you excessive
> pain, I recommend connecting with Robert on ways to make improvements to
> testrepository. Those improvements will also have the effect of improving
> life for the rest of OpenStack, which is also a great reason why we all use
> the same tools rather than foster an environment of per-project snowflakes.
>
> Additionally other folks showed that this is not a blocker for moving
>> under big tent.
>>
>
> I apologize for any confusion that may have resulted from you being given
> erroneous information.
>
>
> __________________________________________________________________________
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151006/1ac410a0/attachment.html>


More information about the OpenStack-dev mailing list