Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Well-known mca parameters
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-04-25 10:25:08


On Apr 24, 2014, at 9:41 PM, Mike Dubman <miked_at_[hidden]> wrote:

> not a requirement of course, but warm recommendation. Like you mentioned:
> "component developers who choose to expose such information do so using the suggested syntax, then that is a different proposal."
>
> >>>FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so please don't include it in such lists to avoid giving anyone even a passing thought that we do so.
>
> I don`t understand, today we have "--with-slurm --with-pmi" for dynamic link with slurm and others where we call slurm functions from OMPI code. how calling slurm.getVersion() is different?

We do *not* dynamically link with libslurm, Mike. All --with-slurm does is tell us to build the Slurm-related RAS and PLM components. Those components do *not* link against libslurm - they (a) read the environment for slurm envars to get the allocation and (b) fork/exec srun commands to launch our daemons. Under no conditions do we ever call a slurm function.

The PMI functions are specifically licensed differently to allow apps to use them without this unfortunate side effect.

>
> afaik, dynamic linking (as we do it today) does not violate current licensing model.

This is *not* true. If you include a slurm header, which you must do in order to call a slurm function, then the GPL license pulls all of OMPI into GPL.

>
>
>
> On Fri, Apr 25, 2014 at 5:39 AM, Ralph Castain <rhc_at_[hidden]> wrote:
> Just for clarification: are you proposing that we *require* every component that links against an external library to include these parameters? If so, that seems a significant requirement as quite a few of our components do so.
>
> On the other hand, if you are proposing that those component developers who choose to expose such information do so using the suggested syntax, then that is a different proposal.
>
> Just want to understand what you are proposing - a requirement on components, or a syntax for those who choose to support this capability?
>
> FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so please don't include it in such lists to avoid giving anyone even a passing thought that we do so.
>
>
>
> On Apr 23, 2014, at 10:38 PM, Mike Dubman <miked_at_[hidden]> wrote:
>
>>
>> WHAT:
>> * Formalize well-known MCA parameters that can be used by any component to represent external dependencies for this component.
>>
>> * Component can set that well-known MCA r/o parameters to expose to the end-users different setup related traits of the OMPI installation.
>>
>> Example:
>>
>> ompi_info can print for every component which depends on external library:
>> - ext lib runtime version used by component
>> - ext lib compiletime version used by component
>>
>> slurm: v2.6.6
>> mtl/mxm: v2.5
>> btl/verbs: v3.2
>> btl/usnic: v1.1
>> coll/fca: v2.5
>> ...
>>
>> End-user or site admin or OMPI vendor can aggregate this information by some script and generate report if given installation compiles with site/vendor rules.
>>
>> * The "well-known" mca parameters can be easily extracted from ALL components by grep-like utilities.
>>
>> * Current proposal:
>>
>> ** prefix each well-known MCA param with "print_":
>> ** Define two well-known mca parameters indicating external library runtime and compiletime versions, i.e.:
>>
>> print_compiletime_version
>> print_runtime_version
>>
>> The following command will show all exposed well-known mca params from all components:
>> ompi_info --parsable -l 9 |grep ":print_"
>>
>>
>> WHY:
>>
>> * Better support-ability: site/vendor can provide script which will check if OMPI installation complies to release notes or support matrix.
>>
>>
>> WHEN:
>>
>> - Next teleconf
>> - code can be observed here: https://svn.open-mpi.org/trac/ompi/ticket/4556
>>
>>
>> Comments?
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14590.php
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14601.php
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14604.php