[ewg] RE: RHEL 5.3 and OFED 1.4.x

[Doug Ledford]

On Wed, 2009-01-28 at 09:38 -0600, Steve Wise wrote:
> Doug Ledford wrote:
> > On Thu, 2009-01-22 at 16:07 -0600, Steve Wise wrote:
> >   
> >> I understand the desire to not release new features in a point release, 
> >> but at the same time, these features are ready or near ready now.  And 
> >> prior features have definitely been released in point releases.  
> >> (connectX for example).  Another key point is that these features do not 
> >> need the kernel rebase that will happen with ofed-1.5, which will take 
> >> months...
> >>
> >> Just more thoughts.  :)
> >>     
> >
> > I'm a bit late to this discussion, and you may have already talked about
> > this in the ewg teleconference, but I want to throw in my thoughts.
> >
> > As far as new features goes, adding ConnectX support in a point release
> > is a huge difference from switching OpenMPI releases from a stable
> > series to the .0 release of the next series.  In the case of ConnectX,
> > it was "just another driver" and its addition should have had almost 0
> > impact on anyone not using that driver.  On the other hand, switching
> > OpenMPI versions changes the OpenMPI stack for everyone and has the
> > potential to create wide spread regressions should something go wrong.
> > So the risk factor comparison between these two actions simply isn't
> > valid.  One doesn't risk regressions for non-ConnectX users, one risks
> > regressions for everyone using OpenSM.
> >
> >   
> Good points.
> 
> One way to alleviate this is to ship both 1.2.8 and 1.3 in ofed-1.4.1 
> and mark 1.3 as "experimental".  Then remove 1.2.8 in ofed-1.5 and make 
> 1.3.x the production version for ofed-1.5.

That's certainly doable IMO.

> I suggested this in the last conf call but folks didn't like the thought 
> of testing both.  But perhaps marking it "experimental" resolves this 
> issue?  So the iWARP vendors will test 1.3 and little to no testing is 
> required for 1.2.8 since it has been qualified with ofed-1.4 QA.

What about adding some automated tests using mpitests?  Both automated
build tests (which does some amount of testing of the mpicc et. al.
wrappers) and run tests (which would require a slightly more
sophisticated test harness in that it at least needs to know about
machines to run the tests over, etc)?

In fact, while I'm at it, let me attach my Makefile patch I use against
the mpitests-3.1 package in OFED 1.4.  It greatly simplifies the make
environment and does something that I think the mpitests package
*should* do but currently doesn't without my patch: test the mpicc
wrappers.  The current Makefiles set all sorts of MPIHOME and CC and
other variables...these are all things that mpicc *should* take care of
for you and *not* using plain mpicc in the mpitests Makefiles simply
ignores one aspect of the testing that is perfectly valid and means you
have to validate your mpi build environment separately.  I would suggest
that this patch, or something like it, be applied to the build
environment for mpitests.  Is the person responsible for that tarball on
these lists?

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpitests-2.0-make.patch
Type: text/x-patch
Size: 5605 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090128/06abd66c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090128/06abd66c/attachment.sig>