On Apr 24, 2014, at 9:41 PM, Mike Dubman <mi...@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 <r...@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 <mi...@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 >> - code can be observed here: https://svn.open-mpi.org/trac/ompi/ticket/4556 >> >> >> Comments? >> _______________________________________________ >> devel mailing list >> de...@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 > de...@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 > de...@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
