* Mike Burns <mburns(a)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(a)us.ibm.com