You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When launching omicron jobs from a singularity container, the corresponding executable path will, in general, not exist in the environment in which the jobs get run. At a high level, it seems like this could be supported by:
introducing a --singularity-image (or similar) to the command line parser that defaults to os.getenv("SINGULARITY_CONTAINER"), which will be the full path to the running container's image if currently inside a container
Add a similar argument to OmicronProcessJob
During OmicronProcessJob.write_sub_file, check if self.singularity_image is not None, and if not add something like this to the sub file
When launching omicron jobs from a singularity container, the corresponding executable path will, in general, not exist in the environment in which the jobs get run. At a high level, it seems like this could be supported by:
--singularity-image
(or similar) to the command line parser that defaults toos.getenv("SINGULARITY_CONTAINER")
, which will be the full path to the running container's image if currently inside a containerOmicronProcessJob
OmicronProcessJob.write_sub_file
, check ifself.singularity_image is not None
, and if not add something like this to the sub fileglue.pipeline.CondorDAGJob
.If this is something the team thinks might be valuable, happy to take a stab at making a PR for this.
The text was updated successfully, but these errors were encountered: