spack-stack 2.0 container configs.

[eap]

This pull request is checking a revision to the release 2.0 containers necessary to remove sp. Because gsibec brings in sp, we will have to configure jedi-ci to build sp. JCSDA-internal/jedi-ci#56

Issues

#1330

JCSDA-internal/jedi-ci#53

Erata notes

These container configs require manual modification of the Docker files in order for their builds to complete. This final modification could be avoided by updating _spack_checkout_config and the bootstrap template in our fork of spack (or potentially via other unconsidered config customizations) but since we plan to deprecate the spack containers in favor of a tier_1 container site, I'm submitting this as-is simply to ensure the history is captured.

Dockerfile fix instrucitons

1. Create the Dockerfile with spack containerize
2. On the ENV declaration on line 4 of the dockerfile add the variable SPACK_STACK_DIR=/opt/spack-stack
3. Replace the run command online 39 with the following clause

RUN git clone --branch release/2.0 --recurse-submodules \
            https://github.com/jcsda/spack-stack.git $SPACK_STACK_DIR && \
    $SPACK_STACK_DIR/setup.sh && \
    ln -s $SPACK_STACK_DIR/spack $SPACK_ROOT

Live containers.

These containers have been pushed with the following "revision 1" tag suffixes.

• Intel OneAPI:   747101682576.dkr.ecr.us-east-2.amazonaws.com/jjedi-oneapi-impi-dev:2.0r1
• GCC 13:         747101682576.dkr.ecr.us-east-2.amazonaws.com/jedi-gcc-openmpi-dev:2.0r1
• GCC 11:         747101682576.dkr.ecr.us-east-2.amazonaws.com/jedi-gcc-openmpi-dev:2.0-gcc11r1

Checklist

• This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.
• [ x All necessary updates to the documentation (spack-stack wiki) will be made when this PR is merged

[ashley314]

Looks good, thanks!

[climbfuji]

I assume we don't merge this back to develop, since you will redo the containers for the 2.1 release?

[eap]

@climbfuji Correct - Correct, no need to merge back to develop. I'm just checking this in because I want to keep tabs on the configs we are using for the active CI containers

(also I didn't include the errata in the first PR, and I should have, I want it written down somewhere and ths PR feels good enough)