[openfabrics-ewg] Draft IBED Positioning Statement

[Scott Bahling]

Hi,

I have been following this thread, and see some confusion about the
difference between the OpenFabrics 1.0 release and the IBED release. To
me it seems clear, because it matches the way we create our distros.
There are official community releases of packages that make up the base
of our distro. The same would be true for IBED which grabs code from
OpenFabrics, kernel.org, Open MPI, OSU MPI, etc...

One tip - IBED should not fork to far, if at all, from these community
code bases. Any patches that end up in IBED should come from (backported
if necessary) the official community trees. This means if bug is first
found in IBED, we need to get it fixed in the community tree first. If
we don't do this, we will end up with code that is difficult to maintain
for any length of time.

What is not clear to me is the stability commitment behind IBED. As an
enterprise customer (end user or ISV), I would expect in that in the
IBED minor releases there are no regressions in functionality or
interfaces (API/ABI), and no (appreciable) regressions in performance
from the initial release major release (1.0?).

The IBED minor releases should provide bug and security fixes and
possible feature enhancements that have been QA'd to ensure no
regressions as stated above. Immediate bug fixes can be delivered to
customers by the distros or vendors, but are eventually rolled into the
standard release. Any fixes to customers should be approved and
submitted to the IBED (and parent community releases if not already
there) svn before providing to the customer - that way insuring the fix
is standardized, and makes it in the next general release.

Also, how long can a customer expect a specific major release to be
maintained and supported? Our experience is that enterprise customers
expect 5-10 years of life.

-Scott

On Thu, 2006-04-06 at 17:48 +0300, Yaron Segev wrote:
> 1. It seems it better include something like: “guarantees cross-vendor
> interoperability”.
> 
> 2. Aviram notes are OK.
> 
> 3. In regards to Tziporet notes, I think its too tightly coupled for
> coming next weeks activities and players names while we want something
> that will cover more in general the process, I would suggest to phrase
> it something like:
> 
> The release build is done in this method:
> 
> 1.      Any module that is already in the kernel will be taken from
> the git tree that is targeted for next kernel release
> 2.      Kernel modules that are not in Linux kernel will be taken from
> openFabrics SVN trunk or ,in extra ordinary cases, from SVN contrib. 
> 
> 3.      All user space code is taken from the 1.0 branch.
> IBED group will make sure the right patches from the trunk are updated
> to the branch.
> 
> 4.      MPI:
> MVAPICH – tarball based on OSU release.
> Open MPI – tarball is provided by open MPI developers.
> Both tarballs are placed in OpenFabrics web site 
> 
> 5.      IBED build & install scripts: all relevant scripts are placed
> under a specific directory for IBED release under the 1.0 branch. 
> 
> 6.      Back port patches: patches directory will be also under the
> IBED directory in the 1.0 branch. 
> 
> The release process:
> 
> The release coordinator will build the release candidate (IBED-rcX)
> and publish it on OpenFabrics (approximately every 2 weeks)
> 
> Each IBED vendor is responsible to test the components under his
> ownership. Bugs are reported through bugzilla and fixes are provided
> to the general list.
> 
> -Yaron 
> 
>  
> 
> ___________________________________________________________
> 
> Yaron Segev |   +972-9-9717650 (o)   |   +972-54-4996631 (m)
> 
> Director, Software Development
> 
> Voltaire – The Grid Backbone 
> 
> www.voltaire.com______________________________________________
> 
> 
>  
> 
>                                    
> ______________________________________________________________________
> From:openfabrics-ewg-bounces at openib.org
> [mailto:openfabrics-ewg-bounces at openib.org] On Behalf Of Tziporet
> Koren
> Sent: Thursday, April 06, 2006 3:40 PM
> To: Shawn Hansen (shahanse); Openfabrics-ewg at openib.org
> Subject: RE: [openfabrics-ewg] Draft IBED Positioning Statement
> 
> 
>  
> 
> See inside in this color (also starting with TK for plain text
> readers)
> 
> Tziporet
> 
> -----Original Message-----
> From: openfabrics-ewg-bounces at openib.org
> [mailto:openfabrics-ewg-bounces at openib.org] On Behalf Of Shawn Hansen
> (shahanse)
> Sent: Thursday, April 06, 2006 4:19 AM
> To: Openfabrics-ewg at openib.org
> Subject: [openfabrics-ewg] Draft IBED Positioning Statement
> 
> All,
> 
> Here is a draft message for submission to openib-general describing
> IBED
> 
> and how it relates to the OpenFabrics release. It is written in a Q&A
> 
> format.
> 
> Please review, and let's quickly drive to consensus on this. We will
> 
> discuss this in detail on the next EWG conference call, which needs to
> 
> be held before the next board meeting.
> 
> --Shawn
> 
> -----------------------------------------
> 
> All,
> 
> We are pleased to announce the creation of the InfiniBand Enterprise
> 
> Distribution (IBED), under the direction of the OpenFabrics Enterprise
> 
> Working Group.
> 
> IBED is a distribution of InfiniBand software that includes the
> 
> OpenFabrics 1.0 release, along with other additional software outside
> of
> 
> the scope of the release, such as MPI.
> 
> Frequently Asked Questions
> 
> --------------------------
> 
> Q: What is the Enterprise Working Group?
> 
> The EWG is a group of hardware vendors that will sell products based
> on
> 
> OpenFabrics.  The purpose of this group is to coordinate how to
> provide
> 
> a single commercially supportable distribution of OpenFabrics software
> 
> to their customers.
> 
> Q: Why is IBED required?
> 
> - Enterprise customers will have solution-level requirements that are
> 
> outside the scope of the 1.0 release, such as the distribution of MPI
> 
> stacks, support for a pre-2.6 kernel releases, etc.  The goal of IBED
> is
> 
> to address this need.  Without IBED, each InfiniBand vendor would
> create
> 
> their own distribution of OpenFabrics to accomplish this goal.
> 
>  TK: regarding kernel version need to say – older kernel then the one
> release by kernel.org (2.6.16 for today)
> 
> Q: Does IBED compete with the OpenFabrics release?
> 
> - No, there is only one OpenFabrics release.  IBED is a distribution
> 
> that includes the OpenFabrics 1.0 release. The OpenFabrics 1.0 release
> 
> and IBED share the same user-level code (libraries, management
> 
> utilities, etc.)  The code for both is taken from the 1.0 branch. 
> 
> Q: Is IBED development happening in the open?
> 
> - Yes, IBED uses the OpenFabrics bugzilla for bug reporting, and all
> 
> discussions can be viewed on the Enterprise Working Group mailing
> list.
> 
>  TK: You can add that all IBED development is done now on 1.0 branch
> under ibed directory
> 
> Q: How does IBED differ from the OpenFabrics release?
> 
> - The OpenFabrics release contains only user-level code, while the
> IBED
> 
> distribution also adds kernel modules that are not part of the Linux
> kernel (like iSER and RDS).
> 
> TK: I think we need to say that IBED included all Infiniband kernel
> modules that are under OpenFabrics development, especially modules
> that are not part of Linux kernel.
> 
> - IBED will include two MPI packages that are not part of Open
> Fabrics:
> 
> OSU MPI and Open MPI.
> 
> - IBED is packaged for end-user installation.
> 
> - IBED supports distribution with older kernels (e.g. Redhat EL4 up2)
> 
> Q: What is the software release process for IBED and how does it
> relate
> 
> to the OpenFabrics release?
> 
> - Insert here.
> 
> TK: The release build is done in this method:
> 
> 1.      Any module that is already in the kernel will be taken from
> the git tree that is targeted for 2.6.17
> This include the following: mthca, ipath, core modules (except CMA
> that is not part of kernel), IPoIB, SRP 
> 
> 2.      Kernel modules that are not in Linux kernel will be taken from
> these directories:
> iSER, SDP, CMA – from the trunk
> RDS: from SilverStorm contrib directory (till they move it to the
> trunk) 
> 
> 3.      All user space code is taken from the 1.0 branch.
> IBED group will make sure the right patches from the trunk are updated
> to the branch.
> 
> 4.      MPI:
> MVAPICH – tarball is provided by Mellanox (Pavel Shamis) based on 0.97
> release of OSU.
> Open MPI – tarball is provided by Cisco (Jeff Squyres)
> Both tarballs are placed in OpenFabrics web site 
> 
> 5.      IBED build & install scripts: all relevant scripts are placed
> under a specific directory for IBED release under the 1.0 branch. 
> 
> 6.      Back port patches: patches directory will be also under the
> IBED directory in the 1.0 branch. 
> 
> The release process:
> 
> Mellanox build the release candidate (IBED-rcX) and publish it on
> OpenFabrics (approximately every 2 weeks)
> 
> Each IBED vendor is responsible to test the components under his
> ownership. Bugs are reported through bugzilla and fixes are provided
> to the general list.
> 
> Q: What is the anticipated release schedule?
> 
> TK: - mid May
> 
> Q: What components will be included in IBED and how is this decided?
> 
> TK: Aviram already sent the full list.
> 
> Decision was taken in the EWG based on customers needs.
> 
> - Insert here.
> 
> _______________________________________________
> 
> openfabrics-ewg mailing list
> 
> openfabrics-ewg at openib.org
> 
> http://openib.org/mailman/listinfo/openfabrics-ewg
> 
> 
> _______________________________________________
> openfabrics-ewg mailing list
> openfabrics-ewg at openib.org
> http://openib.org/mailman/listinfo/openfabrics-ewg