5:18 p.m.
On Tue, 2012-08-21 at 09:10 -0500, Ryan Harper wrote:
* Mike Burns <mburns(a)redhat.com> [2012-08-21 07:29]:
> On Tue, 2012-08-21 at 19:52 +1000, Justin Clift wrote:
> > On 20/08/2012, at 10:02 PM, Mike Burns wrote:
> > > Hi all,
> > >
> > > Now that oVirt 3.1 has shipped, we need to start the planning process
> > > for the next release. One of the major topics for this week's weekly
> > > sync is to review the release criteria.
> > >
> > > The criteria we used for 3.1 is laid out on the wiki [1]. I will be
> > > posting an equivalent version for the next release in the next couple
> > > days, but it will mostly be copy/paste from this page.
> > >
> > > Please think about release criteria and whether or not we want to
> > > add/remove/change things for this release. This needs to be determined
> > > now to make sure that the release process runs smoother down the line.
> >
> > Is there some way we can do an end-to-end platform test for most
> > of the things mentioned there, to sanity check the binaries before
> > announcement?
> >
> > 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.
Mike
>
> Mike
>
> >
> > Regards and best wishes,
> >
> > Justin Clift
> >
> > > Thanks
> > >
> > > Mike
> > >
> > > [1] http://wiki.ovirt.org/wiki/Second_Release
> > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/users
> >
> > --
> > Aeolus Community Manager
> > http://www.aeolusproject.org
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
>
>
> _______________________________________________
> Board mailing list
> Board(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board