Project

General

Profile

Feature #24294

Proper handling of which environment variables to preserve/clear when starting containers

Added by Marco Mambelli 7 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
04/08/2020
Due date:
% Done:

0%

Estimated time:
Stakeholders:

OSG, CMS

Duration:

Description

Preserving/unsetting variables should be handled properly giving clear options and mechanisms.

Consider also Singularity's mechanisms and plans (https://github.com/sylabs/singularity/issues/5040):
  • Singularity forward host user environment variables to container process in various inconsistent and not reproducible ways
  • always forwarded (case insensitive): term, http_proxy, https_proxy, no_proxy, ftp_proxy
  • never forwarded (case insensitive): path, ld_library_path
  • always forwarded but impossible to override from CLI
    • HOME by default uses home directory defined in user database or the source part from --home option
    • PATH always set to "/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin"
    • LANG set to "C" when --cleanenv is specified
  • Variables prefixed with SINGULARITYENV_ see their prefix trimmed and are forwarded to container process no matter if --cleanenv is specified or not ( may or may not take precedence over host user environment variables)
    • SINGULARITYENV_PREPEND_PATH become SING_USER_DEFINED_PREPEND_PATH, SINGULARITYENV_APPEND_PATH become SING_USER_DEFINED_APPEND_PATH, SINGULARITYENV_PATH become SING_USER_DEFINED_PATH

This is how it's expected in Singularity 3.6:

No changes regarding forwarding of user host environment variables

Only variables prefixed with SINGULARITYENV_ are passed to:
/.singularity.d/env/10-docker2singularity.sh or /.singularity.d/env/10-docker.sh
/.singularity.d/env/90-environment.sh
/.singularity.d/env/91-environment.sh
Add --env option to pass environment variables by simply prefixing them with SINGULARITYENV_
and allow to pass environment variable as literal like this:
--env PYTHONPATH=/python/path:\${PYTHONPATH}
Rules:

Docker inherited environment variables are always overridable (stay aligned with docker behaviour)
Environment variables defined in %environment section are overridable only if the image author allow it:
Example for an overridable variable:
%environment
    # if PYTHONPATH is already set use it otherwise use
    # default value "/usr/local/python3" 
    export PYTHONPATH=${PYTHONPATH:-"/usr/local/python3"}
Example for not overridable variable:
%environment
    export PYTHONPATH="/usr/local/python3" 

There should be an option to decide which variables to preserve.
Sets should be provided to keep basic functionalities (but there should be the option to blank those out as well)
Making use of the --env-file option seems the most efficient way to enforce the variables to preserve


Related issues

Related to GlideinWMS - Feature #24295: Update the singularity wrapper w/ new features form the OSG wrapperClosed04/08/2020

History

#1 Updated by Marco Mambelli 7 months ago

  • Related to Feature #24295: Update the singularity wrapper w/ new features form the OSG wrapper added

#2 Updated by Marco Mambelli 7 months ago

The idea is to define a variable to control which variables will be cleared form the environment:
GLIDEIN_CONTAINER_ENV, allows a comma-separated list of the following keywords:
  • clearall - clear all from the environment (at your own risk)
  • osgset - set of OSG variables (get it from OSG wrapper)
  • gwmsset - set of GWMS utilities variables
  • clear - same as: clearall,gwmsset,osgset
  • clearpaths - clear only PATH,LD_LIBRARY_PATH,PYTHONPATH (default)
  • keepall - clear no variable, incompatible w/ any clear... option

A future ticket, after Singularity 3.6 will allow a file w/ a more complex syntax. Keep, remove, override, sets and individual variables
Should I use the condor classad to keep the variables or a GWMS file?

#3 Updated by Marco Mambelli 7 months ago

Code is also in v36/24295

#4 Updated by Marco Mambelli 6 months ago

  • Assignee set to Marco Mambelli
  • Status changed from New to Resolved

Code in v36/24294 (branched off v36/24295)

#5 Updated by Marco Mambelli about 2 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF