Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EESSI-extend and configure_easybuild no longer in sync #802

Open
ocaisa opened this issue Oct 31, 2024 · 1 comment
Open

EESSI-extend and configure_easybuild no longer in sync #802

ocaisa opened this issue Oct 31, 2024 · 1 comment

Comments

@ocaisa
Copy link
Member

ocaisa commented Oct 31, 2024

#710 introduced a change in configure_easybuild to support accelerators but this change has not been incorportated into EESSI-extend. It's not entirely clear how we want to do this either since EESSI-extend supports 4 different scenarios (CVMFS, site, project, user).

Do we want this distinction to apply in all cases? This introduces complexity as the behaviour of the module will depend on whether or not the trigger environment variable (EESSI_ACCELERATOR_TARGET) is set or not, and for the end user there are no protections in place to stop them accidentally installing a CPU build into an accelerator target space. The only "person" automatically setting EESSI_ACCELERATOR_TARGET is the bot, so I think this bit of logic is best suited to the bot build scripts (unless we put protections in place in our EB hooks).

@ocaisa
Copy link
Member Author

ocaisa commented Oct 31, 2024

I guess we could support this for EESSI and site installations since we control the exposure of those module trees.

For the site case, I would probably disable --robot in this case and issue a warning that this has been done so they do not accidentally install CPU-only dependencies into the accelerator stack

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

No branches or pull requests

1 participant