Skip to content

Telcon: 2023 03 29

Jump to bottom Edit New page
Peter Scheibel edited this page Mar 29, 2023 · 19 revisions

Held Wednesday March 29th, 9am PT (UTC -7:00)

Attendees

  • Peter Scheibel (host)
  • Jack Morrison
  • Justin Cook (NERSC)
  • Mark Krentel
  • Massimiliano Culpo
  • Steve Leak (NERSC)
  • Tammy Dahlgren

Agenda

(20 minutes at the end of the meeting is reserved for Q&A)

  • Justin Cook: Best way to deploy Spack on a system?
    • e.g. does each user get their own copy of Spack?
      • yes to that specific question
    • See: https://github.com/spack/spack-configs
      • This includes example configs from a number of sites
    • In general the approach I'd recommend for an admin providing for several users:
      • all users clone Spack
      • the admin prepares a set of configs and environments
        • these can include things like external (system) package installs
        • also things like permission settings
      • you may also want to provide a customized binary cache
    • Justin: concern if everyone has their own version of Spack about synchronizing the commit used by spack
      • Have a module for spack which sets some environment variables
      • Admins share a spack instance and use it to install software for users
      • Unnecessary duplication of Spack files
      • Examples of current pain points with shared Spack:
        • spack edit fails if it ends up targeting the global repo
    • See: https://github.com/spack/spack/pull/11871
    • Steve: overall system
      • There is an upstream which is used to provide shared
      • Environments are created by default in the spack prefix
        • For now, the workaround is to prevent users from creating named environments
    • Patch needed: at some point during the install, Spack changes permissions/ownership for installed prefix
      • TODO: resolve over slack (see the patch diff and errors without patch)
    • Tammy: related permissions handling PR for multi-user Spack: https://github.com/spack/spack/pull/16614
  • Jack: built in utilities that allow me to take action on the age of an installation
    • Massimiliano: spack find can search for installations that fit in a time window (see --start-date and --end-date)
  • Mark: is there a way to specify a version as the latest
    • spack install dyninst@latest
    • Don't want @develop in this case, want the latest fixed revision
    • This overrides "preferred"
    • Moreover, this is not a preference, but rather a hard constraint
    • E.g. in packages.yaml could ask for dyninst@latest
    • In particular if there is reuse, we want to use later versions
      • Does spack concretize -U help with this?
      • Reuse mode: dependencies
        • For an environment this means that explicitly-listed specs do not prioritize reuse, but dependencies are reused
    • See visit: in which case the latest version is deprecated
    • Would it work to say "preferred versions are required for this specific package"?
Add a custom footer
Clone this wiki locally