-
Notifications
You must be signed in to change notification settings - Fork 417
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
Using process.containerOptions instead of docker.runOptions #1431
Conversation
|
I think introducing a new parameter I think the second solution you proposed adheres better to expected usage patterns and the separation of scientific logic and configuration. It would be possible to implement those changes via a module patch right? Also, am I correct in assuming that the goal of this PR is to address #1406 , #1404 , and #1362 ? |
I also don't like the introduction of the new parameter As you mention, we can also decide to go with this solution and make a module patch. |
I think you might be having trouble accessing that config variable because of the hierarchy that configs are resolved in (https://www.nextflow.io/docs/latest/config.html#configuration-file). At the moment in time when this module specific configuration is resolved, |
Hmmm ... That might be so 🤔 However, I see in the case of profile=docker we have |
|
But |
I should add that
In the case I don't suppose something like the following would work:
|
…tainerOptions for SPARK-modules for any kind of container engine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking food
Are you also looking for lunch? I haven't had my lunch yet. |
Sorry I was off base on the config resolution. Good investigation though! |
Thanks for joining in on the discussion, @kenibrewer . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add some docs crosslinking the warning about kubernetes and GLS?
Using process.containerOptions instead of docker.runOptions.
Clearing the containerOptions for the SPARK modules - regardless of which container engine is used. (It should be no problem for Singularity, but unclear whether it is a problem for kubernetes.
I ran the following tests of Singularity+Spark locally: