This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
I thought maybe we should move this to another thread as it really isn't
about Torsten's specific RFC.
I just took a quick gander at the code base to see how extensive this
problem might really be per Terry's concern. What I found was that we have
added 3rd party code in several places. How we want to define them in terms
of this issue is probably something for discussion.
Packages I could readily identify include:
1. event library
5. PLPA - this one is a little less obvious, but still being released as a
There may well be others - these are only the ones I know about. By 3rd
party package, I mean these are blocks of code obtained as a complete,
distinct version and "dropped in" to the OMPI code repository, and then to
some degree tied into our build system. They are not code specifically
developed for OMPI by OMPI developers.
We have already discussed the issues with this approach. I am particularly
concerned with the maintenance and release cycle issues right now.
If these packages could be linked to our code instead of embedded within it,
then it seems to me that updating them could become much easier. For
example, we could download and install the latest ROMIO + Panasas patch,
compile it, and simply link it into libompi - without occupying someone with
constantly fixing the build system issues, etc.
Obviously, I don't claim to know enough about what was done to integrate
ROMIO to know if this would easily work. I only use it to illustrate the
point - the same could be said about the event library, for example.
Given our maintenance support problems, it would seem to me that changing
the way we do 3rd party packaging may be worth consideration and some
effort. I can't prioritize that relative to 1.3, though I do note that, from
LANL's perspective, the ROMIO issue is a definite blocker for 1.3 release.
> Subject: Re: [OMPI devel] [RFC] Non-blocking collectives (LibNBC) merge to
> From: Terry Dontje (Terry.Dontje_at_[hidden])
> Date: 2008-02-07 13:18:36
> Jeff, the below sounds good if we really believe there is going to be a
> whole bunch of addons. I am not sure NBC really constitute as an addon
> than more some research work that might become an official API. So I
> look at the NBC stuff more like a BTL or PM that is in progress of being
> developed/refined for prime time. So would a new PM or BTL be added via
> ompi_contrib? I wouldn't think they would.
> The ompi_contrib sounds like a nice utility but I have feeling there are
> bigger fish to fry unless we really believe there will be a lot of
> addons that we will need to support.
> Jeff Squyres wrote:
>> All these comments are good. I confess that although I should have, I
>> really did not previously consider the complexity of adding in N
>> contrib packages to OMPI.
>> The goal of the contrib packages is to easily allow additional
>> functionality that is nicely integrated with Open MPI. An obvious way
>> to do this is to include the code in the Open MPI tarball, but that
>> leads to the logistics and other issues that have been identified.
>> Ralph proposes a good way around this. But what about going farther
>> than that: what we if we offer a standardized set of hooks for
>> including contrib functionality *after* core OMPI has been installed?
>> Yes, it's one more step after OMPI has been installed -- but if we can
>> keep it as *one* step, perhaps the user onus is not that bad. Let me
>> Consider a new standalone executable: ompi_contrib. You would run
>> ompi_contrib to install and uninstall contrib functionality into your
>> existing OMPI:
>> ompi_contrib --install http://www.example.com/nbc/nbc-ompi-contrib.tar.gz
>> or ompi_contrib --install file:///home/htor/nbc-ompi-contrib.tar.gz
>> This will download NBC (if http), build it, and install it into the
>> current OMPI. It is likely that the nbc-ompi-contrib.tar.gz file will
>> contain the real NBC tarball (or maybe just a reference to it?) plus a
>> small number of hook/glue scripts for OMPI integration (perhaps quite
>> similar to what is in the contrib/ tree [on the branch] today for
>> NBC?). Likewise, after NBC is installed into the local OMPI
>> installation, ompi_info should be able to show "nbc" as installed
>> contrib functionality. It then follows that we might be able to do:
>> ompi_contrib --uninstall nbc
>> to uninstall contrib NBC from the local OMPI installation.
>> This kind of approach would seem to have several benefits:
>> - Keep a clear[er] distinction between core OMPI and contributed
>> - Allow simple integration of MPI libraries, tools, and even
>> applications (!) (think: numerical libraries, boost C++ libraries,
>> etc. -- how many of your users install additional tools on top of MPI
>> incorrectly?). Anything
>> - Allow 3rd parties to have "contrib" code to Open MPI without needing
>> to get into our code tree (and sign the 3rd party agreements, etc.),
>> keeping our distribution size down, avoiding release schedule
>> logistical issues, keeping our "core" build time down, etc.
>> - Allow integration of contrib functionality at both a per-user and
>> system-wide basis.
>> What I'm really proposing here is that OMPI becomes a system that can
>> have additional functionality installed / uninstalled. Based on the
>> infrastructure that we already have, this is not as much of a stretch
>> as one would think.
>> ("who's going to write this" is a question that will also have to be
>> answered, but perhaps we can discuss the code concept/idea first...)
>> On Feb 7, 2008, at 10:11 AM, Ralph H Castain wrote:
>>> I believe Brian and Terry raise good points. May I offer a possible
>>> alternative? What if we only include in Open MPI an include file that
>>> contains the "hooks" to libNBC, and have the build system only "see"
>>> if someone specifies --with-NBC (or whatever option name you like).
>>> If you
>>> like, you can make the inclusion automatic if libNBC is detected on
>>> system. It would make sense to also add -libNBC to the mpicc et al
>>> as well when the build system includes the function definitions.
>>> This would allow those users that want (or can) to use that library
>>> against it, without adding a bunch of source code to our release. I
>>> there are complications that will have to be dealt with, but offer
>>> it as
>>> something to consider.
>>> Also, remember that there is an added burden when we add source code
>>> to Open
>>> MPI that we haven't discussed - we are now adding coordination
>>> issues to our
>>> own release cycle. If libNBC changes, are we now going to be pressed
>>> issue another OMPI release so that the new NBC version is included?
>>> Do we
>>> now need to coordinate our releases with theirs so that things align?
>>> And if we have an increasing number of such "included" packages, how
>>> is -that- release discussion going to get?!?
>>> On 2/7/08 4:48 AM, "Terry Dontje" <Terry.Dontje_at_[hidden]> wrote: