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.
Neves-P
left a comment
There was a problem hiding this comment.
Another small detail that I spotted now and am adding here so I don't forget.
|
The last commit message was supposed to read: "Account for custom prefix installs for .cvmfsdirtab" After that is reviewed, we need to account for the changes in the tarball ingestion step too. That is blocked until EESSI/filesystem-layer#278 is merged. |
Co-authored-by: Pedro Santos Neves <10762799+Neves-P@users.noreply.github.com>
Co-authored-by: Bob Dröge <b.e.droge@rug.nl>
Co-authored-by: Bob Dröge <b.e.droge@rug.nl>
Neves-P
left a comment
There was a problem hiding this comment.
Suggestions with updates accounting for VERSIONS_SUBPATH workflow in ingest-tarball.sh.
Co-authored-by: Pedro Santos Neves <10762799+Neves-P@users.noreply.github.com>
| # We will leverage a script from eessi-bot-software-layer (for signature verification - optional) | ||
| git clone https://github.com/EESSI/eessi-bot-software-layer.git | ||
|
|
||
| # We will leverage a script from filesystem-layer (for tarball ingestion) | ||
| git clone https://github.com/EESSI/filesystem-layer.git |
There was a problem hiding this comment.
Having these here will break things for a second run, as these dirs will already exist. We should either add a check, or maybe just let people do this manually and add a variable for the paths to these dirs at the top? I think I'd prefer the latter, makes it a bit more flexible in case you want to (temporarily) modify these scripts, e.g. for testing.
| if [ $? -eq 0 ]; then | ||
| echo "Tarball signature file downloaded." | ||
| else | ||
| echo "WARNING: Failed to download tarball signature file. Continuing to next tarball (not ingesting ${filename})." | ||
| # No point in continuing this loop iteration, we'll fail the signature verification check anyway | ||
| continue | ||
| fi |
There was a problem hiding this comment.
This basically does mean that it's not optional, as it will now entirely skip tarballs with a signature file. Maybe we should have another variable at the top that allows people to enable/disable the signature checking? If it's enabled but the sig file(s) cannot be downloaded -> hard error for that tarball. If it's disabled, don't even try.
No description provided.