Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

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