Meeting 2016 02

Feb 2016 OMPI Developer's Meeting

Dates:

• Start: 9am Tuesday, February 23, 2015
• Finish: 1pm Thursday, February 25, 2015

Location:

• IBM Dallas Innovation Center web site
• Google Maps
• Street address: 1177 South Beltline Road, Coppell, Texas 75019 USA

We've been told there are a number of hotels that will shuttle both to/from DFW and the IBM Innovation Center. Geoff Paulsen (@gpaulsen) is working on a list now, and will update once he has a list of hotels.

Attendees

Local attendees:

1. Jeff Squyres - Cisco
2. Ralph Castain - Intel

Suggested topics:

1. Now that high-speed networks can be accessed via multiple network stacks (and multiple Open MPI components), users are getting confused about how to (un)select specific networks. We need to figure out a better / easier way for users to convey what they want. See http://www.open-mpi.org/community/lists/devel/2015/10/18154.php for more detail.
   1. One (very loose and probably not yet well thought-out) idea is to have some kind of higher-level abstraction: --[enable|disable] NETWORK_TYPE:QUALIFIER
2. Mellanox/LANL have raised a good point that customers do not want to have multiple different Open MPI installations in their environments (e.g., Vendor A OMPI and Vendor B OMPI and community OMPI).
   1. How can a customer have a single OMPI installation, but still have vendor/distribution-specific enhancements?
   2. Or is that the wrong question -- should we really be working to enable individual component distribution? This would disallow vendors from distributing patches to core.
3. Can we double check that all vendor Open MPI distributions are appropriately marked? E.g., via --with-ident-string? Not sure how to do this other than to ask each vendor/distribution -- perhaps we should default to "Unknown distribution" and have the nightly/release scripts set the official strings...?
4. Re-discuss the separation of our libraries into libmpi, libopen-rte, and libopen-pal.
   • Beginning of the project: there was just libmpi. Later, it was split into projects, and then the project libraries. Later, the build was unified back into libmpi again.
   • In Dec 2012 (here's the commit), we split the build back into 3 libraries. The commit message cites discussion at the Dec 2012 Open MPI dev meeting -- but there's unfortunately no clues as to the rationale why this was done in the wiki notes. Was it just because we developers like having 3 smaller libraries? Or is there some deeper technical issue? Neither Ralph nor Jeff remembers. 😦
   • Rationale for bringing this up again: when upstream projects are trying to link against portions of our project, and then also support apps that link against all of it, we run into conflicts (e.g., the ORTE being used by the upstream project may be different than the one being used by the OMPI installation). Slurping it all up into one library would resolve the problem - but we cannot recall if there are undesirable side-effects.