Skip to content

Conference call notes 20190206

Jump to bottom
Kenneth Hoste edited this page Feb 6, 2019 · 13 revisions

(back to Conference calls)

Notes on the 119th EasyBuild conference call, Wednesday Feb 6th 2019 (17:00 - 18:00 CET)

Attendees

Alphabetical list of attendees (8):

  • Eduardo Arango (Sylabs)
  • Fotis Georgatos (SDSC, Switzerland)
  • Adam Huffman (Big Data Institute, UK)
  • Victor Holanda (CSCS, Switzerland)
  • Kenneth Hoste (HPC-UGent, Belgium)
  • Mikael Öhman (Chalmers University of Technology, Sweden)
  • Bart Oldeman (ComputeCanada)
  • Davide Vanzo (Vanderbilt University, US)
  • (+1 more?)

Agenda

  • report on 4th EasyBuild User Meeting
  • follow-up on moving Python to GCCcore
  • standard (container-based) testing environment
  • Q&A

Report on 4th EasyBuild User Meeting

  • commonly requested features

    • support for uninstalling
      • relevant PR by Miguel?
      • cfr. IT4Innovations eb wrapper
    • Python 3 support
      • Victor is working on it actively
    • better logging/error reporting
      • Spack approach makes sense: use CMake regex patterns for "zooming in" on errors/warnings in logs
      • should also pick up config.log and include it in EasyBuild log?
        • Mikael also CMakeCache.txt (+ CMakeOutput.txt/CMakeErrors.txt)

  • integration EasyBuild with ReFrame

    • already done via EasyBuild hook by Victor (CSCS)
    • WIP @ CSCS

  • Spack talk

    • some ideas that could be useful to EB

  • query about progress with .yeb easyconfigs (YAML syntax)

    • Alan has been keeping it alive (sort of)

Follow-up on moving Python to GCCcore + multi-Python installations of Python packages

  • cfr. https://github.com/easybuilders/easybuild-easyconfigs/issues/7463

  • remote talk by ComputeCanada @ EUM has some useful info on this

  • Mikael: 2nd option of using PythonCore is a pain in practice

  • put together working group for this?

    • Kenneth could work on Python easyconfigs for 2019a that follow the proposed approach

  • Bart: PR that adds support for iterating over builddependencies

    • cleanup PR would help
    • may try do that for 2019a generation as well (but needs work in framework + PythonPackage easyblock)
    • Mikael: how does that work for (non-Python module) libraries that link to libpython*.so?
      • we can still fall back to the current approach to install separately for separate Python versions
      • Victor: there are cases where this sort of thing "just works"

Standard (container-based) testing environment

  • Singularity image(s)?
  • OS:
    • CentOS 7.x (cfr. EUM survey)
    • OpenHPC based?
    • more later?
  • modules tool: Lmod vs environment-modules
  • arch: only x86_64 initially
    • can also consider POWER (via Micael's boxes and/or QEMU) and ARM (QEMU)
      • cfr. setup at CÉCI (Frédéric Wautelet, UNamur)
  • EasyBuild installation
    • inside or outside container?
    • latest release vs current develop (there are use cases for both)
  • minimal vs fat installation
    • both are needed for good test "coverage" (cfr. problems with Boost system installation)
    • slightly less minimal environment needed to build GCCcore, can be stripped down later (no g++, etc.)
  • software/modules installation prefix outside of container
    • standard setup, e.g.:
      • /apps installation prefix which can be bind-mounted into container?
        • bind-mounted paths need to be pre-created to use CentOS 6.x host (related to overlay FS)
        • Fotis: /opt/easybuild is registered as a standard somewhere
          • Mikael: XDG standard?
      • build dir in /tmp (or optionally /dev/shm)
  • could use Sylabs remote builder + Sylabs library
    • limited resources for building images, not enough for building toolchains from scratch
    • Singularity 3.0 supports pushing pre-built (signed) images to Sylabs library
  • not limited to only testing easyconfigs, can also be leveraged to tests easyblocks/framework

Other

  • (Kenneth) intel/2019a vs Intel compilers/impi/imkl 2019 update 2 releases
    • ship has sailed?
    • probably to painful to still change it, not worth the trouble
    • depends on changelog?
    • can define intel/2019.02, to let people drop-in replace that for intel/2019a
Clone this wiki locally