search

DUNE-DAQ / daq-release

Scripts and configuration files for the DUNE DAQ release
https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/
2 stars 0 forks source link

Proposal for the layout of spack installation on cvmfs #127

Closed dingp closed 2 years ago

dingp commented 2 years ago

The following pieces related to spack managed releases will need to be deployed to cvmfs:

  1. The spack tool itself;
  2. site-wide spack configuration;
  3. spack repository for external packages;
  4. spack repository for each release;
  5. the installation of external packages;
  6. the installation of DAQ packages in each release;
  7. Spack environment (release specific).

A proposal of the cvmfs layout is:

Since spack likes to manage the installation of packages and environments under $spack (spack root), and it provides the view tool to view those packages, it is easier to have item 5, 6, 7 under spack root (/cvmfs/dunedaq.opensciencegrid.org/tools/spack/vX.X.X).

When we advance to a new spack version, the new version can "import" the older version as "upstream" spack instance, so all of the packages installed by the older spack become available with the newer spack.

For the nightly release, we will use the spack for frozen releases in the dunedaq cvmfs repo as the upstream installation, so that the externals can be reused. The layout of nightly release can be the following:

dingp commented 2 years ago

Trying this layout under: /cvmfs/dunedaq-development.opensciencegrid.org/sandbox.

dingp commented 2 years ago

Changing the layout a little bit:

dingp commented 2 years ago

After today's weekly SW Coordination discussion, we agreed on the following layout of spack related elements on cvmfs:

Main cvmfs repo /cvmfs/dunedaq.opensciencegrid.org/

This is the repo where frozen releases will be put under.

  1. Top level subdirectories spack-installation contains the spack tool itself and packages installed via it;
  2. spack-externals contains the dune-externals spack repo;
  3. spack-releases contains the release related files, including:
    • the release YAML file;
    • generated spack repo for the release;
    • requirements file for python virtual environment;
    • prebuilt python virtual environment;
    • cmake build order file;
    • dbt-setttings file if required by the spack flavored dbt.

:green_heart: All things related to spack will be put under directories with leading spack- in the names. So they are totally decoupled from existing UPS releases. :green_heart:

├── products                        # UPS related, can be retired after fully transitioned to spack
├── pypi-repo
├── releases                        # UPS related, can be retired after fully transitioned to spack
├── setup_dunedaq.sh
├── spack-externals 
├── spack-installation
├── spack-releases
└── tools

Development cvmfs repo /cvmfs/dunedaq-development.opensciencegrid.org/

This is the repo where nightly releases will be put under. Spack installation here will use the spack in the main repo as upstream spack instance, so that the external dependencies can be re-used.

  1. spack-installation contain the tool itself and packages installed via spack. In this case, the packages will be DAQ packages only, as the external dependencies are brought in from the main repo;
  2. spack-nightly will be equivalent to spack-releases in the main repo; it contains the nightly releases. The contents of each nightly releases are similar to those frozen releases too;
├── nightly                          # UPS related, can be retired after fully transitioned to spack
├── products                         # UPS related, can be retired after fully transitioned to spack
├── sandbox
├── spack-installation
└── spack-nightly
dingp commented 2 years ago

One possible major change of layout for discussion:

While testing with multiple nightly releases, I found spack makes containerizing single release (frozen or nightly) harder than expected since it put packages from different releases all under opt/spack.

Spack itself maintains a database (in json format) of packages installed in it. For two nightly releases, that db in json is a ~10,000 line-file (and nightly instances only contains DAQ pacakges). It’s doable to play with that json db, and only pick packages in a release based on the namespace identifier, similar adding new nightly releases built by CI jobs. However, it will certainly be error-prone, as this is not something spack supports natively (combining/separating packages of different instances).

A proposal is to make dedicated spack instances for different releases and additionally the externals will have its own instance which is used by release instances.

dingp commented 2 years ago

The cvmfs sandbox deployment has been prepared and deployed to cvmfs. Details of the preparation can be found in: #130.

@jcfreeman2 Instructions to use these spack releases is posted here.

dingp commented 2 years ago

The production deployment has been published to cvmfs.

It has been recreated with a SL7 container (previously CS8 container). CS8 has a newer glibc version. The pre-built release made on CS8 is not backward compatible.