On Mon, 09 Nov 2009 09:30:36 +0100 Andreas Kuntzagk <andreas.kuntzagk@mdc-berlin.de> wrote:
Nate Coraor wrote:
Andreas Kuntzagk wrote:
Before adding it to galaxy main I'd suggest reworking the parameter-part of the URL. It looks ugly and confusing as it is. (but I cant come up with something better ATM :-( )
This is our hesitation as well, but we've come up with an idea that we hope is cleaner: define them as requirements in tool_conf.xml, like so:
<tool file="filters/headWrapper.xml"> <runner name="GalaxyProject"> <requests virtual_free="7G"/> <parallel_environment>threads 4</parallel_environment> </runner> </tool>
Where 'GalaxyProject' is a 4-field runner URL as described by Assaf.
This looks much cleaner. (Moving the runner config to the tool_conf was also somewhere on my wish list.)
I'm not so sure. I think it makes sense to keep all the SGE tool config in one place rather than strewn across various tool XML files. If the admin were to need to change some settings or migrate to a new set-up, it would be a nightmare to find them all. I would advocate keeping it in the universe_wsgi.ini file.
Only grief I have with this is that you need to have a complete mapping of SGE (or Torque) parameters to XML elements in Galaxy (and in the documentation). Or would you also have something generic like <other_argument>-l my_limit</other_argument> ?
The way I read the above is that the <requests> tag fulfils the -l role. i.e. qsub -l foo=bar would map to: <requests foo="bar" />. So it is generic already. I agree, though, that this system does require a full mapping of all the options. Assaf's solution at least only requires a knowledge of the qsub parameters. I've no idea if Assaf's solution is problematic for other schedulers or if there are security implications via passing of raw parameters, but I prefer his implementation TBH. Cheers, Chris