search

aces / cbrain

CBRAIN is a flexible Ruby on Rails framework for accessing and processing of large data on high-performance computing infrastructures.
GNU General Public License v3.0
71 stars 42 forks source link

ToolConfigs to auto-propagate env variables to singularity #1266

Closed prioux closed 1 year ago

prioux commented 2 years ago

Our ToolConfig model allows the admin to configure environment variables settings for the tool, e.g. ABC=xyz. These setting are transformed into a set of export ABC=xyz statements in the job script.

When a tool is run within Singularity, these environment variables will be propagated by default into the container, except if the admin configures the --cleanenv (or -c) option when singularity is invoked (in the ToolConfig attribute container_exec_args which shows up as 'Misc Singularity options in the page). In that case the admin must either

  1. add explicitly another --env ABC=xyz (or better --env ABC=$ABC) in the Singularity options
  2. change the name of the environment variables in the ToolConfig env table so they get prefixed with "SINGULARITYENV_" (e.g. "SINGULARITYENV_ABC")

Option 1 means redundancy in defining the environment variables, and option 2 means that the tool config's environment table is now 'aware' of the containerized situation, which can lead to inconsistency when configuring the exact same tool without a container.

In order to make the life of the admin easier, I suggest that whenever a tool is launched through singularity, the set of export statements created by the ClusterTask object be replaced (or extended) with assignments of the form export SINGULARITYENV_ABC=xyz.

MontrealSergiy commented 2 years ago

Hi @prioux ,

I guess I can duplicate all variable export with the prefixed names and add text warning to the tool config form. Which would result in more variables than needed yet less intrusive and problem ridden then renaming variable in the place

In the current version I tried to implement it with boutiques module because:

  1. I prefer explicit to implicit. I considered addition 'propagate variable to container' button into config yet I guess you would deem over-engineering (extra complicated)
  2. There are situation when change of variable name is undesirable a) some variable can control singularity, e.g. some supercomputers recommend placing the singularity cache into the 'data' folder rather then 'home', this only can be done with an environment variable b) eventually, SINGULARITYENV is to be deprecated into the favor of APPTAINERENV
prioux commented 2 years ago

A boutiques module doesn't help in the case of tasks not implemented with Boutiques.

MontrealSergiy commented 2 years ago

A boutiques module doesn't help in the case of tasks not implemented with Boutiques.

valid point, though majority of new tools are deployed with boutiques. Well, I can try without boutiques, ok