Thanks Greg,

In case you are not aware of it, the Galaxy tool shed wiki explains the tool shed:  http://wiki.g2.bx.psu.edu/Tool%20Shed

I am aware, thanks, although I won't exclude the possibility that I've misunderstood something ...

I've "inherited" a galaxy setup from someone (details: a contractor set it up but left it unfinished so I'm completing the job while discovering and documenting what was done). The catch: it's setup as a twin galaxy instance with one as a front-end web-server and the other as the job runner.

Just to confirm, you have set up a single Galaxy instance (with a single database on the back-end) with multiple web front-ends - is this correct?

Right - a single database with one web front-end and one job-runner. And here's a detail that I forgot and may be important ... they're on different machines. They share the db and a shared data space but are on different VMs.

The Galaxy tool shed is a separate application that has no dependencies on a Galaxy instance (and vice-versa), although a Galaxy instance and a tool shed instance can each communicate with the other, so your question is a bit confusing.  A single Galaxy tool shed can be used by any number of Galaxy instances, so if you create a repository in a tool shed instance and upload tools to it, any number of Galaxy instances will be able to access that tool shed and install the repositories from it.

Right - but setting up the toolshed is not the confusing point for me. It's how the job-runner gets to use a tool installed from a toolshed when it's on a different machine to the front-end. The tool has to be installed into the job-runner as well, right? 

As said, I inherited this system, so I'm discovering how it's been setup.

cheers

p
--
Paul Agapow (pma@agapow.net)