Skip to content

Conference call notes 20171122

Jump to bottom
Kenneth Hoste edited this page Nov 22, 2017 · 3 revisions

(back to Conference calls)

Notes on the 90th EasyBuild conference call, Wednesday November 22nd 2017 (5pm - 6pm CEST)

Attendees

Alphabetical list of attendees (5):

  • Damian Alvarez (JSC, Germany)
  • Fotis Georgatos (Illumina, UK)
  • Kenneth Hoste (HPC-UGent, Belgium)
  • Alan O'Cais (JSC, Germany)
  • Davide Vanzo (Vanderbilt University, USA)

Agenda

  • report on EasyBuild activity at SC17
  • outlook to EasyBuild v3.5.0
  • discussion on (optionally) including glibc in toolchains
    • workaround for future occurrences of RHEL vs Intel compilers issues?
  • Q&A

Notes

EasyBuild @ SC17 (Davide)
  • cake! http://easybuilders.github.io/easybuild/images/easybuild5.png
  • Davide talked with Michigan State University (& others) at booth talks, who showed interest
  • some interest with OpenPOWER
    • current way they are managing software installations is... meh
    • currently: large GitHub repository with bash scripts
      • URL?
    • suggested EasyBuild as a saner approach
    • Davide may get access to a POWER system to help out with this
    • Alan has some experience with this already
      • CUDA is a pain, installation method used in EB is not available on POWER (and won't be)
      • similar issue for Spectrum MPI (RPM install, non-relocatable)
        • Alan's workaround was to use SystemMPI easyblock
  • no extra info about inclusion of EasyBuild in latest Bright Computing release
    • may be interesting to invite BC to EUM'18 (also for Fotis himself)
  • people who attended EasyBuild booth talks were asking about
    • module naming schemes, what is being exposed to users (concerned with end user experienced)
    • how to integrate EasyBuild in current setup
    • should be better documented?
      • "How To Get Started With EasyBuild" page?
      • also experiences/use cases from other sites
    • big gap in docs: using custom module naming scheme
Outlook to EasyBuild v3.5.0
Including glibc in future toolchains?
  • triggered by problems with CentOS 7.3/7.4 updates vs Intel compilers
    • also helps with build reproducibility
  • experiences with building own glibc?
  • Damian: what about security aspects of this?
    • less of an issue compared to system glibc, which is used for everything incl. stuff run as root
    • glibc used in toolchain & for scientific software is only used in 'user land'
  • Damian: is this going to be a problem in the future, are we solving a problem that won't happen again?
  • in any case, inclusion of glibc provided through EasyBuild should be made optional through configuration option?
  • should use RPATH for glibc libraries
    • helps (a little bit) with security concerns
    • avoids breaking system tools like cp & co
  • compatibility of glibc in toolchain with Linux kernel on updates?
  • feedback from ComputeCanada who are using own glibc via Nix layer
  • Fotis: GNU Guix does a trick with including placeholder paths that are patched later...
    • used for relocation of installations
    • ref?
  • Nix talk @ HUST'17
    • presenter is also going to join EUM'18 in Amsterdam
Other topics
  • Fotis: Shahzeb's buildtest (https://github.com/shahzebsiddiqui/buildtest) at FOSDEM/EUM?
    • Shahzeb contacted Kenneth, plans to submit talk proposal for buildtest to FOSDEM
    • can maybe also be presented at EasyBuild User Meeting?
  • Davide:
    • sharing Core installations between system with different processor architectures?
    • motivation is mostly reducing of used disk space
    • maybe binary installations should be installed somewhere else (other than Core)
      • e.g. Binary (all binary installations) & Core (compilers, that open up subdir in Compiler level) on top of hierarchy -> Compiler -> MPI
      • Binary installations only need to be installed once, can be shared across architectures
      • Core installations are still architecture-specific
      • e.g. CUDA, MATLAB, ...
    • also helps discriminating between compilers (that give access to other stuff) & pure binaries
    • GCC build is built for specific architecture by default (beyond our control?)
      • cross-compilation support?
      • potential impact on performance of GCC itself?
  • question from Maxime on making exceptions to dependencies being filtered out via --filter-deps
    • cfr. https://github.com/easybuilders/easybuild-framework/issues/2351
    • use case:
      • EasyBuild is configured with --filter-deps=flex,... to leverage flex provided by OS (or actually Nix)
      • some builds don't work with too recent flex, so then EasyBuild-provided flex could/should be used
    • seems like a case for configuring with --hide-deps=flex instead of --filter-deps=flex?
    • add support to specify exception in easyconfig to overrule --filter-deps feels backwards...
  • feedback on idea to add toolchain option to specify whether linking to sequential or multi-threaded BLAS should be done?
Clone this wiki locally