We have a similar scenario. In their infinite wisdom, our system admins have insisted on install pbs pro which we do not think will be compatible with the torque libs. We want to run normal processes locally and outsource specific tools to the compute cluster by writing a tool that submits a pbs script. If we can just run a monitor on a working directory for the output files to turn up - with a timeout - that would be good enough.
Cheers Dennis
On Sat, May 29, 2010 at 5:47 AM, Andrey Tovchigrechko atovtchi@jcvi.orgwrote:
We have decided to use a local Galaxy install as a front-end to our metagenomic binning tool MGTAXA ( http://andreyto.github.com/mgtaxa/ ) I need some guidance from the Galaxy developers for the best way to proceed:
- The server will be on a DMZ, with no direct access to the internal
network, where the computes will be running on a local SGE cluster. The best that our IT allowed is for some script on the internal cluster to monitor a directory on the web server, pull input/tasks from where when they appear, put the results back. My current idea is to have the Galaxy "local runner" to start "proxy jobs": each proxy job is a local process that does "put the input into watched dir; until results appear in the watched dir; sleep(30); loop; finish". In other words, Galaxy thinks that it is running jobs locally, but it fact those jobs are just waiting for the remote results to come back. Does that look like a sane solution? How will it scale on the Galaxy side? E.g. how many such simultaneous tasks can the local runner support? Any anticipated gotchas? Additionally, we will be also trying to run computes on our TeraGrid account. I was thinking that the solution above can be applied to that scenario also, except that now the proxy job would be polling qsub on TeraGrid through ssh, or call Globus API. Here one problem is that a job often has to wait in a TeraGrid queue for 24 hours or so. Will my proxy jobs on Galaxy time out/get killed by any chance? The alternatives are 1) write another runner (in addition to local, sge, torque) - how much work it will be? 2) write a fake SGE python interface and make Galaxy think it is using local SGE
- What repo is best to clone, given the scope of our activity described
above? We will likely need to mess a bit with the Galaxy internals, not just the tool definition. Should we clone galaxy-central or galaxy-dist? What workflow would you recommend for updating, submitting patches etc?
I will be very grateful for answers to the above, and also to any alternative recommendations. Andrey
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev