Bug #9703
closed[Crunch2] CWL workflow failed with Crunch2, but passed with Crunch1
Updated by Radhika Chippada over 8 years ago
I ran Jiayong's varscan CWL workflow (main-goCallVars.cwl) in 9tee4.
When I used the command "arvados-cwl-runner --local --wait --debug main-goCallVars.cwl test-input-yml/main-goCallVars-job.yml" the pipeline instance https://workbench.9tee4.arvadosapi.com/pipeline_instances/9tee4-d1hrv-wgvlm9an4a6caw6 was created and succeeded. It had 7 successful jobs.
When I it ran using "--api containers", i.e. Crunch2, it created a container request https://workbench.9tee4.arvadosapi.com/container_requests/9tee4-xvhdp-hdeyli0ct23pwsf . This had two children (freebayes and varscan) and the freebayes CR is failing.
(venv)radhika@shell.9tee4:~/goCallVars/goCallVars$ arvados-cwl-runner --local --wait --debug --api containers main-goCallVars.cwl test-input-yml/main-goCallVars-job.yml (venv)radhika@shell.9tee4:~/goCallVars/goCallVars$ arvados-cwl-runner --api containers --submit --no-wait main-goCallVars.cwl test-input-yml/main-goCallVars-job.yml
Updated by Brett Smith over 8 years ago
9tee4 is currently trying and failing to dispatch a container for one of these workflows because it does not specify a number of CPUs in its runtime constraints. Once we upgrade the API server here, this container request wouldn't even be valid.
I think the bug here is that arvados-cwl-runner needs to fill in default constraints in cases where the workflow doesn't specify them. Otherwise, it might end up trying to submit invalid container requests to the API server.
Updated by Peter Amstutz almost 7 years ago
- Status changed from New to Resolved
a-c-r sets resource defaults