Document approaches for site builds on top of EESSI - #778
Conversation
first attempt at writing the shared fs section
…, after a reboot, the stratum 0 overlay won't mount
…cript. Also, added a full, copyable script combining all the previous components.
Neves-P
left a comment
There was a problem hiding this comment.
Looks really nice! This is my first pass of comments, as of know I only focused on the text. This week I will follow the documentation in practice and review again.
|
|
||
| Another thing to consider is to create a secondary user with `aws iam create-user --user-name <name>` and attach a very limited policy to it (e.g. only read/write/list on buckets, nothing else). Then, create credentials for this user with `aws iam create-access-key --user-name <name>` and provide those credentials to the EESSI build bot and Stratum 0 machines. That way, if that token is compromized, the impact is minimized (e.g. the token can at least not be used to create new IAM idententies, etc). | ||
|
|
||
| ## Setting up the EESSI build bot |
There was a problem hiding this comment.
I'd consider separating this into a new page. The build bot is somewhat self contained and the page is quite long already.
|
|
||
| Another thing to consider is to create a secondary user with `aws iam create-user --user-name <name>` and attach a very limited policy to it (e.g. only read/write/list on buckets, nothing else). Then, create credentials for this user with `aws iam create-access-key --user-name <name>` and provide those credentials to the EESSI build bot and Stratum 0 machines. That way, if that token is compromised, the impact is minimized (e.g. the token can at least not be used to create new IAM idententies, etc). | ||
|
|
||
| ## Setting up the EESSI build bot |
There was a problem hiding this comment.
I realize these docs lack one crucial thing: setting up a site_config_script that sets EESSI_SITE_INSTALL_FORCE and EESSI_SITE_SOFTWARE_PATH_PREFIX
There was a problem hiding this comment.
I.e. at SURF, our site_config_script looks like this:
# To build on top of EESSI, we need to software.eessi.io repository to be mounted next to our own repository
# The bot/build.sh script does this when the EESSI_SITE_INSTALL_FORCE environment variable is set
# Other build scripts will also respect this variable where needed in order to make sure that 'building on top'
# of EESSI is possible
export EESSI_SITE_INSTALL_FORCE=1
echo "Value of EESSI_SITE_INSTALL_FORCE: $EESSI_SITE_INSTALL_FORCE"
# We also need to set a prefix that our installations should end up in
# The build scripts should take this prefix, and construct the final EESSI_SITE_SOFTWARE_PATH out of it
# that the EESSI-extend module expects
export EESSI_SITE_SOFTWARE_PATH_PREFIX=/cvmfs/software.surf.nl/versions/2025.06/
echo "Value of EESSI_SITE_SOFTWARE_PATH_PREFIX: $EESSI_SITE_SOFTWARE_PATH_PREFIX"
One thing to figure out might be how to avoid hard-coding the version in here :)
There was a problem hiding this comment.
Scratch that, this should not be needed anymore... I think we do this differently now... We automatically set these here https://github.com/EESSI/software-layer-scripts/blob/ca929cd7ef32a9fcd79fafd4e0d5c362a1fff452/bot/build.sh#L156 . That happens if the repo_name in the repos config file is unequal to software.eessi.io or dev.eess.io essentially.
There was a problem hiding this comment.
I think this does warrant a small explanation of why EESSI_SITE_SOFTWARE_PREFIX, EESSI_SITE_INSTALL and friends are not needed with this workflow. Maybe we don't even need an explanation, but just a mention.
I'm saying this because going through the whole docs - especially the shared file system installs - you get the impression that at least doing EESSI_SITE_INSTALL is necessary for site installations (which it is, but that happens behind the scenes).
Neves-P
left a comment
There was a problem hiding this comment.
Just two comments, suggestions. I would have liked to have been more thorough, but overall I did two passes to the text and managed to get to the point of installing the bot (had to wait a bit for the internal S3 and maintenance).
In my mind, after addressing these comments we can either wait a little longer and I spin up a new test CVMFS infrastructure to also test that part, or merge before that and address any thing else we spot in a later PR.
Overall I think the instructions are very nice! I'm not sure I am able to put myself in the shoes of a complete novice to EESSI, but they seem very appropriate for that target audience.
|
|
||
| Another thing to consider is to create a secondary user with `aws iam create-user --user-name <name>` and attach a very limited policy to it (e.g. only read/write/list on buckets, nothing else). Then, create credentials for this user with `aws iam create-access-key --user-name <name>` and provide those credentials to the EESSI build bot and Stratum 0 machines. That way, if that token is compromised, the impact is minimized (e.g. the token can at least not be used to create new IAM idententies, etc). | ||
|
|
||
| ## Setting up the EESSI build bot |
There was a problem hiding this comment.
I think this does warrant a small explanation of why EESSI_SITE_SOFTWARE_PREFIX, EESSI_SITE_INSTALL and friends are not needed with this workflow. Maybe we don't even need an explanation, but just a mention.
I'm saying this because going through the whole docs - especially the shared file system installs - you get the impression that at least doing EESSI_SITE_INSTALL is necessary for site installations (which it is, but that happens behind the scenes).
| ``` { .bash .copy } | ||
| curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" | ||
| unzip awscliv2.zip | ||
| sudo ./aws/install |
There was a problem hiding this comment.
This can be installed in userland, and ideally I'd do so. That's how I normally install it in the dev.eessi.io bots and it works well.
|
|
||
| The standard deployment method for the EESSI build bot is to stage tarballs in an S3 bucket. While the bot's functionality may be extended in the future (the [function](https://github.com/EESSI/eessi-bot-software-layer/blob/29dc5e9aa339c323a900dc1454d39246def73984/tasks/deploy.py#L689) actually uploading the tarballs could easily be altered to deploy to a central directory on a local filesystem, for example), for now this means we need an S3 bucket if we want to use the bot's deployment functionality. | ||
|
|
||
| There is extensive documentation on how to interact with S3 buckets available online - here we only list the few commands that you would commonly need to set up a staging bucket. Note that you can create the bucket from anywhere - but you'll need the AWS commands to be available on the machine where you [install the EESSI build bot](#install-eessi-build-bot-on-a-machine), so you might as well set it up there directly. |
There was a problem hiding this comment.
| There is extensive documentation on how to interact with S3 buckets available online - here we only list the few commands that you would commonly need to set up a staging bucket. Note that you can create the bucket from anywhere - but you'll need the AWS commands to be available on the machine where you [install the EESSI build bot](#install-eessi-build-bot-on-a-machine), so you might as well set it up there directly. | |
| There is extensive documentation on how to interact with S3 buckets available online - here we only list the few commands that you would commonly need to set up a staging bucket. Note that you can create the bucket from anywhere - but you'll need the AWS commands to be available on the machine where you [install the EESSI build bot](#install-eessi-build-bot-on-a-machine), so you might as well set it up there directly. You don't necessarily need to use Amazon AWS S3 buckets, for example, if you have access to object storage on a Ceph cluster. The only requirement is that the `aws` tool can read and write to your endpoint. |
No description provided.