On Apr 24, 2014, at 9:41 PM, Mike Dubman <miked@dev.mellanox.co.il> 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@open-mpi.org> 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@dev.mellanox.co.il> 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
  

Comments?
_______________________________________________
devel mailing list
devel@open-mpi.org
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@open-mpi.org
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@open-mpi.org
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