Skip to content

Conversation

lrbison
Copy link
Collaborator

@lrbison lrbison commented Jun 16, 2025

Update to pcluster-amazonlinux2 stack: install intel compilers to the in-docker-image buildcache.

Add a readme and testing files.

@lrbison
Copy link
Collaborator Author

lrbison commented Jun 24, 2025

Let me detail what is changing regarding the compilers, specifically the intel compiler in this PR and GCC in #62 and how they are made available to the runner.

Old Process

Previously the docker image built GCC 12 and installed it within the container. Additionally it pushed GCC and its dependencies into a local build cache within the container. As a manual step we would push the contents of this buildcache to a bootstrap cache (https://bootstrap.spack.io/pcluster/amzn2). We have a script that helps customers install spack by first installing GCC 12 from that manually-pushed buildcache, and then configuring it as a compiler so that the applications posted to cache.spack.io's buildcache would concertize using the same compiler, allowing the application to be installed from scatch.

The pcluster-amazonlinux2 stack also includes applications compiled by Intel OneAPI Compilers. To comply with the license we did not distribute binary cache of this package, but instead installed the compiler into the runner's docker image in order to build the applications, and had customers use our helper script to trigger the installation of the same version when customers installed spack.

New Process

Now, for what changed: With the introduction of compilers as nodes both the compiler and the application can be posted into the same buildcache and the install is smart enough to install both as needed. This allows us to remove the extra step of the helper script adding a build-cache just for the compiler as we did before.

However with spack 1.0 we still cannot do not have the ability to do the concretization in phases that would allow the stack to bootstrap its own compiler, so we must still perform some kind of bootstrapping. PR #62 did that while also changing from including a local install directory, to instead using only in-container cache (with the new cache format), and then use the pre-run hooks to install from this in-container hash in the runner. When the stack is finished building, all specs, including the newer GCC, get pushed to cache.spack.io.

Unlike GCC, the Intel OneAPI Compilers package will not but posted to the public cache, however we still need the compilers installed in the runner in order to build the stack. In this PR I choose to post the Intel compiler in to the local in-container cache by using the --private option when creating that repository, rather than using the pre-configured install path as before. This allowed me to remove the entire spack install path from the runner images, using only the local, private repository.

After this PR is merged and spack.cache.io is populated, I expect we can update https://github.com/spack/spack-configs/blob/main/AWS/parallelcluster/postinstall.sh so that it no longer needs to reference the bootstrap cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant