-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2013 03:53 AM, Tim Flink wrote: > On Thu, 31 Oct 2013 07:17:03 -0400 (EDT) Josef Skladanka > <jskla...@redhat.com> wrote: >> I do not really feel that this is a good match for our needs (at >> least without any significant hacking) > > Yeah, this matches what I remember finding when I looked into this > a couple of months ago. It looks like a better protocol overall > but it's going to be quite a bit more upfront work to support than > TAP. I know that openstack's test suite uses subunit for nova and > neutron [1] > > [1] https://wiki.openstack.org/wiki/Testr > > Subunit has been recently added to the fedora repos but I suppose > that's of little utility for us if we end up having to re-implement > parts to get away from UnitTest.
As Tim noted, subunit development is tied in to the OpenStack project's "test repository" (testr) project. So, if you were going to go down the subunit path, I'd suggest looking at leveraging (at least pieces of) testr for result storage as well. While it's not an urgent requirement, we also plan to explore adding subunit support to Beaker. Robert Collins gave a decent talk on testr (et al) at the PyCon AU 2013 OpenStack miniconf: https://www.youtube.com/watch?v=Oe_HhBBbqbw Looking at the list of Producers and Consumers on the TAP wiki doesn't give me any confidence that *anyone* has successfully used TAP at scale or as part of a distributed continuous integration system, nor does it look like it has anyone providing the level of investment HP and others are putting into the OpenStack testing infrastructure (Robert works for HP, mostly on the OpenStack-on-OpenStack project). Even if subunit is more work initially, you'll likely enjoy flow-on effects in the future from those OpenStack investments (similar to the way LMR decided to outsource the "inventory management and scaling to multiple labs" problems for autotest to Beaker, so autotest gets to avoid doubling up on work we were going to do anyway). With subunit as the more expressive protocol, it also means it would be easier to convert TAP streams to subunit streams than the other way around, so building the back end to be subunit based doesn't rule out the possibility of permitting TAP based input in the future. By contrast, using TAP as the base *will* almost certainly rule out accepting subunit streams from testr or Beaker. Regards, Nick. - -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJScyPEAAoJEHEkJo9fMO/LR8QH/iLHZCA0f87FT1nWzZe9UKOM H0V2Pd+NdubHrHruxsNAhzwdfgZhc3JhW+515hR53LkYti5XlceP/cqUtS1o2YfQ U2qFjkEJ1Fu4+jTVD6a7XO1CejeDHN9SJ+lAKQr+yw7lzCrsmb+GkfMkYPhw/8/5 4B0S9soOCs9Jasl3PwhFvx+1eso3r/+ZYUt6w8IpcDM4PSHhgjoZdQ/Xg7Tmi/js 3qcpEDS9eJCpKJ1KlCG01gFEAxmKBC86dku/Rb3Dy7FYPCBwOFkerYAD89QLaPrX 1pEbIKM77F0e6FoxthEjweALAztdI20uuH0mYisd6HfQAThPPyzOmjuRNY9VJVE= =pNIi -----END PGP SIGNATURE----- _______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
