Open Stack

Yuri,

sticking to global requirements and interacting deeper with OpenStack Infra are up-to-date objectives for Fuel and those are pretty much technical question. However, software development is not only solving technical tasks, it also incorporates interaction between people and other teams so you cannot separate those thinks, even if it sounds too much like politics.

- romcheg

> 7 жовт. 2015 р. о 13:20 Yuriy Taraday <yorik.sar at gmail.com> написав(ла):
> 
> On Wed, Oct 7, 2015 at 12:51 AM Monty Taylor <mordred at inaugust.com <mailto: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.
> 
> It saddens me that once again choice of library is being forced upon a project based on what other projects use, not on technical merit. py.test is more than just a (way better) test runner, it allows to write tests with less boilerplate and more power. While its features are not extensively used in Fuel code, switching to testr would still require changing test logic which is generally bad (that's why mox is still in use in OpenStack). Can we avoid that?
> 
> 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 <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.
> 
> So it seems that all that's needed to keep py.test as an option is a plugin for py.test that generates subunit stream like Robert said, is that right?
> 
> 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.
> 
> I wouldn't call py.test a snowflake. It's a very well-established testing tool and OpenStack projects could benefit from using it if we integrate it with testr well.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/77f15e1c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/77f15e1c/attachment.pgp>