Open Stack

On 10/06/2015 06:01 PM, Thomas Goirand wrote:
> On 10/06/2015 01:14 PM, Yuriy Taraday wrote:
>> On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko <me at romcheg.me
>> <mailto:me at romcheg.me>> wrote:
>>
>>      Atm I have the following pros. and cons. regarding testrepository:
>>
>>      pros.:
>>
>>      1. It’s ”standard" in OpenStack so using it gives Fuel more karma
>>      and moves it more under big tent
>>
>>
>> I don't think that big tent model aims at eliminating diversity of tools
>> we use in our projects. A collection of web frameworks used in big tent
>> is an example of that.
>
>  From the downstream distro point of view, I don't agree in general, and
> with the web framework in particular. (though it's less a concern for
> the testr vs pbr). We keep adding dependencies and duplicates, but never
> remove them. For example, tablib and suds/sudsjurko need to be removed
> because they are not maintainable, there's not much work to do so, but
> nobody does the work...

The Big Tent has absolutely no change in opinion about eliminating 
diversity of tools. OpenStack has ALWAYS striven to reduce diversity of 
tools. Big Tent applies OpenStack to more things that request to be part 
of OpenStack.

Nothing has changed in the intent.

Diversity of tools in a project this size is a bad idea. Always has 
been. Always will be.

The amount of web frameworks in use is a bug.

>>      2. It’s in global requirements, so it doesn’t cause dependency hell
>>
>> That can be solved by adding py.test to openstack/requirements.

No, it cannot. py.test/testr is not about dependency management. It's 
about a much bigger picture of how OpenStack does development and how 
that development can be managed.

> I'd very much prefer if we could raise the barrier for getting a 3rd
> party new dependency in. I hope we can talk about this in Tokyo. That
> being said, indeed, adding py.test isn't so much of a problem, as it is
> widely used, already packaged, and maintained upstream. I'd still prefer
> if all projects were using the same testing framework and test runner
> though.

As I said earlier in this thread, it has already been decided by the TC 
long ago that we will use testr. Barring a (very unlikely) TC rescinding 
of that decision, OpenStack projects use testr. There is zero value in 
expanding the number of test runners.