[Users] Next Release Planning

[Ryan Harper]

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