* Mike Burns <[email protected]> [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 [email protected] _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
