* Mike Burns <mburns@redhat.com> [2012-08-21 09:25]:
On Tue, 2012-08-21 at 09:10 -0500, Ryan Harper wrote:
Trying to think of some way to catch the "broken ISO" problem that 3.1 has with NFS storage. So, something similar doesn't occur again in future.
Any ideas?
Yes, this makes a lot of sense to me. We should make an end-to-end sanity test with all components part of the release criteria.
I haven't seen much discussion around testing the complete stack as a whole. I'm wondering if the all-in-one build makes a good platform to build stack testing against?
I don't really enjoying fixing up jboss or selinux or various other tweaks on test day when installing from scratch (though that does find some bugs), so all-in-one seems like a good sanity check.
From there, building/writing some tests using either engine-cli, or the ovirt-sdk python bindings seems like a good way to exercise the function of the release.
With the nested mode supported, would it be possible to have a jenkins job run a test that booted the all-in-one iso and ran some tests against that?
Just want to point out that ^^ wouldn't catch that ovirt-node is un-usable due to a kernel/vdsm bug. allinone testing is a good idea to catch many issues, but we need to be running some sort of end-to-end testing with ovirt-node as well.
Booting the image is the starting point. One of the tests to run on-top of an all-in-one would be attempting adding an NFS export domain from localhost. And the list goes on. Depending on the complexity of the tests, it may not lend itself to a jenkins job, but I think approach of writing engine level FVT and running it against the all-in-one is sound. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com