Skip to content

openmpi: get rid of implicit system dependencies#16758

Merged
adamjstewart merged 4 commits intospack:developfrom
skosukhin:openmpi_explicit_dependencies
May 26, 2020
Merged

openmpi: get rid of implicit system dependencies#16758
adamjstewart merged 4 commits intospack:developfrom
skosukhin:openmpi_explicit_dependencies

Conversation

@skosukhin
Copy link
Copy Markdown
Member

@skosukhin skosukhin commented May 22, 2020

Currently, openmpi has there implicit dependencies, which it tries to find in the system directories (see _verbs_dir(), _mxm_dir(), and _tm_dir()). This PR makes those dependencies explicit and the users now can specify custom prefixes to those libraries in packages.yaml.

  1. Function _verbs_dir() is removed. Instead, openmpi depends on rdma-core:
    depends_on('rdma-core', when='fabrics=verbs')`
    If the users want to use libraries from the system directories, they need to specify rdma-core as an external package in packages.yaml:
    packages:
      rdma-core:
        paths:
          rdma-core: /usr
          buildable: False
  2. Function _mxm_dir() is removed. Instead, openmpi depends on a new dummy package mxm:
    depends_on('mxm', when='fabrics=mxm')
    mxm can't be installed with Spack (at least for now) and needs to be specified in packages.yaml:
    packages:
      mxm:
        paths:
          mxm: /opt/mellanox/mxm
          buildable: False
  3. Function _tm_dir() is removed. Instead, openmpi depends on a new package pbspro openpbs:
    depends_on('openpbs', when='schedulers=tm')
    pbspro openpbs can be installed with Spack. It depends on a new package libical and a new virtual package sendmail provided be a new real package ssmtp. Although pbspro openpbs can be installed with Spack, I can't guarantee that it will be usable: I don't have experience with the package to test it properly. Additionally, its scripts do not seem to properly account for the case when the package is installed to a non-system directory. Therefore, I would recommend the users to specify it as an external package too:
    packages:
      openpbs:
        paths:
          openpbs: /opt/pbs
          buildable: False
  4. Package lsf is updated to allow for:
    $ spack spec openmpi schedulers=lsf
    $ spack fetch lsf

@skosukhin skosukhin force-pushed the openmpi_explicit_dependencies branch from 10da26d to 0cd82b8 Compare May 22, 2020 12:35
@skosukhin skosukhin force-pushed the openmpi_explicit_dependencies branch from 0cd82b8 to 72bcb2f Compare May 22, 2020 12:38
Copy link
Copy Markdown
Member

@adamjstewart adamjstewart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, I like the idea of explicitly listing external dependencies in packages.yaml.

@hppritcha can you review this? @alalazo may also be interested

@hppritcha
Copy link
Copy Markdown
Contributor

hppritcha commented May 23, 2020

👍 for the Open MPI part. We really should also remove all these ancient versions (anything older than the 2 series). We (Open MPI devel team) never even check now if these versions can compile on, say rhel8.
I can't speak to all the PBSpro changes/additions.

@adamjstewart
Copy link
Copy Markdown
Member

We really should also remove all these ancient versions (anything older than the 2 series).

I started an issue to discuss this in #15896

@skosukhin skosukhin force-pushed the openmpi_explicit_dependencies branch from 6aa886f to f2216d7 Compare May 25, 2020 19:40
@adamjstewart adamjstewart merged commit 15d2883 into spack:develop May 26, 2020
@skosukhin skosukhin deleted the openmpi_explicit_dependencies branch May 26, 2020 08:17
@sethrj
Copy link
Copy Markdown
Contributor

sethrj commented Feb 16, 2021

@skosukhin One of the cluster's spack toolchains I maintain uses an installation of Torque rather than "pbspro", which died in concretization with its limitation of Python 2. A little history shows PBS to have forked into OpenPBS, PBSPro, and Torque. Do we need to add a virtual package "pbs" to allow the use of all three?

For the moment, I have worked around the issue by disabling the python requirement in the openpbs package and adding an external install pointing to the torque location with buildable false. (It concretized but is still building; I'll update this post if the build fails.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants