Hi Davide & Miguel,

With Lmod, there's another option: you can selective hide modules from users, without breaking existing 'module load' commands, to actively discourage them from using old installations for example.

This can be done in various ways, e.g. by putting .modulerc files in place, or by implementing the isVisible hook (cfr. Ward's hook implementations at https://github.com/TACC/Lmod/tree/master/contrib/more_hooks)


regards,

Kenneth

On 28/06/2017 01:01, Miguel Costa wrote:
Hello Davide,

On 28 Jun 2017 02:43, "Vanzo, Davide" <davide.va...@vanderbilt.edu <mailto:davide.va...@vanderbilt.edu>> wrote:

    So, I gave it a try and it works fine.

    The only annoyance (since it is more a matter of style) is that
    once I add the $EB_GLOBAL_PREFIX/modules/all to the $MODULEPATH,
    Lmod output for "module avail" gets pretty crowded.


I know what you mean :)

I was simplifying, I don't actually expose modules/all to normal users by default (they can always add it later, either by changing MODULEPATH directly or running "module use ...")

Besides the module classes and hidden modules, what works for me is grouping the modules by toolchain (could this be added as a feature?) and exposing those groups separately

This has allowed me to, for instance, "deprecate" toolchains that created problems in many of our applications (again, users can add them back manually)

You call also use the ordering in MODULEPATH to put a desired group at the top or bottom of the output of "module avail" (it would be interesting if lmod had a customizable "module shortlist" command...)

Don't know how all this changes if you're using HMNS (see Alan's message)

Miguel




-- Davide Vanzo, PhD
    Application Developer
    Advanced Computing Center for Research and Education (ACCRE)
    Vanderbilt University - Hill Center 201
    (615)-875-9137 <tel:%28615%29%20875-9137>
    www.accre.vanderbilt.edu <http://www.accre.vanderbilt.edu>

    On Jun 27 2017, at 10:43 am, Vanzo, Davide
    <davide.va...@vanderbilt.edu <mailto:davide.va...@vanderbilt.edu>>
    wrote:

        Thank you all for the great suggestions!

        DV


        On Jun 27 2017, at 3:14 am, Miguel Dias Costa
        <migueldiasco...@gmail.com <mailto:migueldiasco...@gmail.com>>
        wrote:



            On 27/06/17 15:42, Alan O'Cais wrote:
            That is a neat trick with the sourcepaths that I will try
            out today.

            I have to credit boegel, he told me about it, I had simply
            assumed that would not work :)


            I think there is a bit more to a user install space than
            what's been mentioned when you have a HMNS, see
            https://github.com/hpcugent/easybuild-framework/issues/2143
            <https://github.com/hpcugent/easybuild-framework/issues/2143>

            ah... because there are then two roots to the hierarchy,
            the global one and the local one?

            Miguel


            On 27 June 2017 at 03:09, Fotis Georgatos
            <fo...@mail.cern.ch <mailto:fo...@mail.cern.ch>> wrote:


                Hi Miguel,

                Yeap! i’d also fully applause this approach, it is
                very similar to what we’ve been doing since 2012!
                - $MODULEPATH can include both global and local
                builds, you just need to decide their exact order
                  * fyi. recent versions of Lmod have in ./contrib a
                pair of use.own.eb modulefiles, implementing the above
                - the global install, is nothing more than by yet
                another user, which just happens to be steered by admin
                - i also encourage people to add a versionsuffix with
                their initials and maybe a date, to keep things apart

                The trick with EASYBUILD_SOURCEPATH is quite nice, it
                could also be used within use.own.eb/* modulefiles,
                assuming that it is always *prepend*, as you described.

                F.

                On Jun 27, 2017, at 1:57 AM, Miguel Costa
                <migueldiasco...@gmail.com
                <mailto:migueldiasco...@gmail.com>> wrote:
                > Hello Davide,
                >
                > I also had doubts initially because of what you
                mention and also using global source paths, but this
                works for us:
                >
                > - create and manage a cluster-wide software stack
                with an easybuild user, using
                EASYBUILD_PREFIX=$EB_GLOBAL_PREFIX
                >
                > - for normal users
                >
                >   - set EASYBUILD_PREFIX=$HOME/.local/easybuild but
                add $EB_GLOBAL_PREFIX/modules/all to the $MODULEPATH
                (so that it finds the already globally installed
                software)
                >
                >   - set
                
EASYBUILD_SOURCEPATH=$HOME/.local/easybuild/sources:$EB_GLOBAL_PREFIX/sources,
                in this order (so that it downloads to local but
                looks in global). This was recently clarified in the
                documentation, last line in
                
https://easybuild.readthedocs.io/en/latest/Configuration.html?highlight=sourcepath#sourcepath
                
<https://easybuild.readthedocs.io/en/latest/Configuration.html?highlight=sourcepath#sourcepath>
                >
                > I think this is enough.
                >
                > Miguel
                >
                > P.S. I encourage users to always add a
                versionsuffix in case they are rebuilding a package
                that already exists globally, otherwise which one
                gets picked depends on the order of the folders in
                $MODULEPATH


                --
                echo "sysadmin know better bash than english" | sed
                s/min/mins/ \
                  | sed 's/better bash/bash better/' # signal
                detected in a CERN forum










-- Dr. Alan O'Cais
            E-CAM Software Manager
            Juelich Supercomputing Centre
            Forschungszentrum Juelich GmbH
            52425 Juelich, Germany

            Phone: +49 2461 61 5213 <tel:+49%202461%20615213>
            Fax: +49 2461 61 6656 <tel:+49%202461%20616656>
            E-mail: a.oc...@fz-juelich.de <mailto:a.oc...@fz-juelich.de>
            WWW: http://www.fz-juelich.de/ias/jsc/EN
            <http://www.fz-juelich.de/ias/jsc/EN>


            
------------------------------------------------------------------------------------------------
            
------------------------------------------------------------------------------------------------
            Forschungszentrum Juelich GmbH
            52425 Juelich
            Sitz der Gesellschaft: Juelich
            Eingetragen im Handelsregister des Amtsgerichts Dueren
            Nr. HR B 3498
            Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen
            Huthmacher
            Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
            (Vorsitzender),
            Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing.
            Harald Bolt,
            Prof. Dr. Sebastian M. Schmidt
            
------------------------------------------------------------------------------------------------
            
------------------------------------------------------------------------------------------------




Reply via email to