Changes to shared stacks on developer infrastructure

Data Management DM Notifications
#1

A selection of new “shared stack” installations of the lsst_distrib metapackage plus associated tools is now available on the lsst-dev developer infrastructure. These new stacks provide updated third-party libraries, support for new compilers and, in some cases, are available with Python 3. In all cases, you should use the devtoolset-6 package in conjunction with these stacks.

The following stacks are available:

  • /ssd/lsstsw/stack2_20171021 is based on Python 2. It is located on local, SSD based storage attached to the lsst-dev01 system: it will support fast interactive use on that machine, but is not accessible across the network.
  • /ssd/lsstsw/stack3_20171021 is based on Python 3. It is located on local, SSD based storage attached to the lsst-dev01 system: it will support fast interactive use on that machine, but is not accessible across the network.
  • /software/lsstsw/stack2_20171022 is based on Python 2. It is located on GPFS-based network storage; as such, it is cross-mounted across a variety of LSST systems at NCSA.
  • /software/lsstsw/stack3_20171023 is based on Python 3. It is located on GPFS-based network storage; as such, it is cross-mounted across a variety of LSST systems at NCSA.

All of these stacks will be regularly updated to provide the latest weekly versions of lsst_distrib. Other packages may be installed upon request.

For convenience, the stacks may be accessed using the following symbolic links:

  • /ssd/lsstsw/stack: Use whatever local stack is the default.
  • /ssd/lsstsw/stack2: Use the latest Python 2-based stack on local storage.
  • /ssd/lsstsw/stack3: Use the latest Python 3-based stack on local storage.
  • /software/lsstsw/stack: Use the whatever networked stack is the default.
  • /software/lsstsw/stack2: Use the latest Python 2-based stack on networked storage.
  • /software/lsstsw/stack3: Use the latest Python 3-based stack on networked storage.

The following older stacks are also available. These will not be regularly updated or supported. Do not use a devtoolset package when accessing these stacks.

  • /ssd/lsstsw/stack_20170409: The old default local stack, based on Python 2.
  • /ssd/lsstsw/stack3_2017-09-11: A prototype Python 3-based stack.

For full documentation on how to use the available developer infrastructure, including these shared software stacks, please refer to the Developer Guide. (But note that information about the new stacks is currently undergoing review, and so may not be available immediately.)

2 Likes
#2

Thanks @swinbank! Can we make the old GPFS-based python 2 stack available too? I naively tried

[yusra@lsst-dev01 ~]$ source /software/lsstsw/stack_old_20171029/loadLSST.bash 
-bash: /software/lsstsw/stack/eups/bin/setups.sh: No such file or directory

and it looks like it would work if we updated some paths in /software/lsstsw/stack_old_20171029/eups/bin/setups.sh

#3

Note that the default stack is now Python 3.

#4

Note also that all local packages need to be cleanly recompiled against the new stack with devtoolset-6 enabled. Failing to do so can give all sorts of weird errors (most likely segfaults).

  1. Check if you have devtoolset-6 by typing gcc --version and see if the output is the expected gcc 6.3.1. If you find an older version then execute: scl enable devtoolset-6 bash and reload the shared stack (you are now in a new shell session).
  2. Clean your package, easiest with git clean -dfx.
  3. Setup: setup -r . and build with scons.
#5

Thanks for prodding on this — I kinda hoped nobody would notice… :slight_smile:

I had to adjust more paths than just those: eups/bin/setups.sh also needed editing, and some scripts (notably pytest) had the installed path written directly into them. I think I’ve caught them all (at least, I got to the level that I can run a bunch of unit tests and things seem to work): please let me know if that does the trick.

#6

That’s why shebangtron exists…

#7

You might want to consider changing this to a scons -c, as that won’t blow away untracked files. Not that I just accidentally deleted some work by blindly following your instructions or anything… The one situation where git reflog won’t save you :roll_eyes: