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: Mike Dubman (miked_at_[hidden])
Date: 2014-04-25 00:43:04


Also, the reason for rfc is this:

https://svn.open-mpi.org/trac/ompi/ticket/4556#comment:5

On Fri, Apr 25, 2014 at 7:41 AM, 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?
>
> afaik, dynamic linking (as we do it today) does not violate current
> licensing model.
>
>
>
> 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
>>
>
>