[openfabrics-ewg] Getting EWG off to a rapid and positive sta rt
Florin, Reini
rflorin at silverstorm.com
Thu Mar 16 11:52:14 PST 2006
Speaking for SilverStorm, I agree fully with Sujal's process suggestions and process proposal below with one added comment.
Since the EWG will be a distribution not a release, I think it is important that we make sure we cover the two primary goals that were the genesis of the EWG concept 1) Provide a single distribution to users that has multivendor guaranteed component interoperability and 2) Provide a distribution to users that has supportable, enterprise class components
I suggest that the distribution, in addition to the "support" based classifications Sujal suggests below also incorporate "interoperability" based logic in the component classifications.
One suggested expanded definition approach to Sujal's below:
1) Basic Component = All vendors that will be offering the EWG distribution to the market agree to interoperability, enterprise quality, and support for basic components (IE. Core, IPoIB, etc.)
2) Add-on Component = Full multivendor interoperability and support is not guaranteed to the user for an add-on component but the component is guaranteed to be enterprise quality and support for the component is provided by one or more vendors (IE. iSER, SRP, SDP, etc)
3) Technology preview = No multivendor interoperability guarantee and no vendor support at all ..... these components are at your own risk components in the distribution (MVAPICH?)
Reini Florin
Vice President of Marketing
SilverStorm Technologies
780 Fifth Ave, Suite 140
King of Prussia, PA 19406
Tel: 610 233-4854
Cel: 203-906-3570
Fax: 610 233-4777
E-mail: rflorin at silverstorm.com
www.silverstorm.com
-----Original Message-----
From: openfabrics-ewg-bounces at openib.org [mailto:openfabrics-ewg-bounces at openib.org]On Behalf Of Sujal Das
Sent: Thursday, March 16, 2006 1:51 PM
To: Openfabrics-ewg at openib.org
Subject: RE: [openfabrics-ewg] Getting EWG off to a rapid and positive sta rt
Bryan ,
Thanks for leading the discussion. I have tried to address some of the questions in the proposal below.
All,
Here is a strawman proposal for the EWG Distribution process. I would like to call a meeting of the EWG members on Monday between at 11:30 AM PST (this time works for the folks in Israel). PLEASE CONFIRM:
KEY PEOPLE in the process:
1. The EWG needs a CHAIR, per Open Fabrics Bylaws who needs to be approved by the BOD. The Chair is a liaison between the EWG and the BOD. Will communicate the existence and purpose of the EWG to OpenFabrics-General.
2. RELEASE COORDINATOR who drives the upcoming release. Drives decisions collaboratively to enable stable, supportable release of EWG Distribution on schedule. Defines: Which software components are included? Which hardware components are intended to work?
3. Open Fabrics Release Committee Lead - the OFR LEAD (what Bryan from PathScale is today)
4. TEST LEADS from each Company. Decides: Which distros are targeted? What is the test matrix? What documentation will be written up for customers?
5. MAINTAINERS and backups (B-MAINTAINER) for each component in EWG: Calls dedicated technical meetings to ensure delivery, code/feature completeness.
Suggested schedules:
EWG Distribution 1.0 - sync with OFR Release 1.0 date of May 8.
EWG Distribution 1.1 - Sept (4 months delta between releases)
Proposal for electing the KEY PEOPLE:
1. CHAIR is elected on a rotating basis - changing every 4 months with EWG release completions. Represented by system companies - Cisco, Voltaire, SilverStorm. In alphabetical order. So, starts with Cisco as the CHAIR. Storage vendors like LSI if they meet the criteria to a EWG member can be eligible to be CHAIR as well. First proposed rotation is after EWG Distribution 1.1 (May 8 being too close). If that is a problem, it could be Matt representing a neutral party.
2. RELEASE COORDINATOR is elected from either Mellanox or PathScale on a rotating basis - changing every 4 months with EWG release completions. Change will be decided when the time comes based on voting or recent past effectiveness etc. This person must be commercially neutral to the system companies who compete in the end user space. At any time Mellanox or PathScale will be the RELEASE COORDINATOR or OFR LEAD, not both. Currently Pathscale is OFR LEAD. So Mellanox will be RELEASE COORDINATOR. First possible rotation (based on voting, effectiveness etc.) is after EWG Distribution 1.1 (May 8 being too close)
3. OFR LEAD is elected from either Mellanox or PathScale on a rotating basis - changing every 4 months with EWG release completions. Change will be decided when the time comes based on voting or recent past effectiveness etc. This person must be commercially neutral to the system companies who compete in the end user space. At any time Mellanox or PathScale will be the RELEASE COORDINATOR or OFR LEAD, not both. Currently Pathscale is OFR LEAD. So Mellanox will be RELEASE COORDINATOR. First possible rotation (based on voting, effectiveness etc.) is after EWG Distribution 1.1 (May 8 being too close)
4. TEST LEADS - elected by individual companies. Scott from Cisco, Bob from SST, Moni from V, Amit from Mellanox, Betsy from Pathscale.
5. MAINTAINERS (B-MAINTAINERS): Selected based on who is currently maintaining. MAINTAINER selects B-MAINTAINER based on technical expertise, past contributions. Here are MAINTAINERS and suggestions for B-MAINTAINERS:
o MTHCA - Roland (Michael Tsirkin)
o IPATH - Roland (Bryan)
o Core - Roland (Bryan)
o IPoIB - Roland (Eli Cohen)
o SDP - Michael Tsirkin (?)
o SRP - Roland (Vu)
o iSER - Moni (?)
o RDS - Todd (?)
o MVAPICH - ?? (ideally would like companies with vested interest to productize MVAPICH)
o Open MPI - ?? (ideally would like companies with vested interest to productize Open MPI)
o OSM - Eitan (Hal) (ideally would like companies with vested interest to productize OSM)
o Diagnostic Tools - Eitan (Hal)
RELEASE COMPONENT CATEGORIES:
They fall under 3 categories:
o BASE COMPONENTS: IPoIB, SDP, SRP, iSER, RDS, Open MPI, iPath, MTHCA
o Depending on vendors desire/ability to qualify and support BASE COMPONENTS - some may be released and supported by vendors as TECH PREVIEW only. E.g., iSER could be TECH PREVIEW for Cisco. SRP could be TECH PREVIEW for Voltaire. RDS could be TECH PREVIEW for all etc. The goal is to get TECH PREVIEW components graduate to supported BASE COMPONENTS in the EWG Distribution 1.1 scheduled for September.
o ADD-ON - These will be added in Vendor specific distributions as add-ons on top of (and not replacing) BASE COMPONENTS. OSM, Proprietary SM, Proprietary MPI, other value added management and tools etc fall in this category
EWG DISTRIBUTION MANAGEMENT + SYNCH WITH OFR RC BRANCH
Copy a specific trunk/branch version to EWG area you can call this a tag. The main idea of a tag is that you do not commit changes to the tagged area.
In addition there is a directory called patches where EWG places the fixes wanted that were not in the trunk/branch. The OFR LEAD folds those into the OFR-RC branch immediately. Coordinated with RELEASE COORDINATOR as necessary.
Continue copy of trunk/branch to the tag few times till EWG gets to the point it wants to freeze code. From this point (regression test phase) EWG only adds patches (some can be EWG fixes and some from the trunk/branch).
We need a discussion on the contents of the OFR rc1 branch - whether it meets the need of end users defined by the EWG and if that needs to be updated (as rc2) based on feedback from EWG.
Thanks
Sujal
-----Original Message-----
From: Bryan O'Sullivan [ mailto:bos at pathscale.com]
Sent: Thursday, March 16, 2006 9:36 AM
To: Openfabrics-ewg at openib.org
Subject: [openfabrics-ewg] Getting EWG off to a rapid and positive start
Hello -
I'll be PathScale's engineering and testing representative on the EWG.
I would suggest that we start by clarifying the goals of the EWG
process, so that everyone is in sync.
My principal interest is in ensuring that there is no duplicated or
wasted effort between the 1.0 process and the EWG process, and that each
can proceed at its own appropriate pace with maximal cooperation between
the two.
What I believe is a good way to achieve this is as follows.
Somebody needs to articulate the goals of the EWG process, and the
timeline in which it will take place. Here are some suggestions I have.
* The existence of EWG should be made public on openib-general,
and it must be made clear that there is cooperation, not
duplication, between the 1.0 and EWG processes.
* Which software components are included?
* Which hardware components are intended to work?
* Which distros are targeted?
* What is the test matrix?
* What documentation will be written up for customers?
* How long is the support window?
* What's the policy with respect to switching to the official 1.0
and subsequent releases?
To get the testing and defect fixing balls rolling as quickly as
possible, EWG contributors ought to use the 1.0 release candidate tree
at https://openib.org/svn/gen2/branches/1.0/ as its initial basis for
source code to build and test. You can download source tarballs and
some RPM packages from http://openib.red-bean.com/
It's fine with me if EWG branches from 1.0 so that it can proceed at its
own pace. However, if this happens, there must be frequent merges
between the two trees, because clearly everything that happens in one
branch ought to be beneficial to the other.
The mechanism that EWG uses to track defects should be OpenIB Bugzilla.
I believe it's already configured in an appropriate manner. If not, I
will be happy to make any needed changes, or ask our colleagues at
Sandia to help out.
<b
_______________________________________________
openfabrics-ewg mailing list
openfabrics-ewg at openib.org
http://openib.org/mailman/listinfo/openfabrics-ewg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20060316/264365d4/attachment.html>
More information about the ewg
mailing list