Hi Peter,<div><br></div><div>I had similar issues and had success setting up galaxy this way:</div><div><br></div><div>(1) Per-group settings:</div><div><br></div><div>I wanted per-group settings as different groups in my organization owned their own SGE clusters or fair-share allocation (each group either submits to the same cluster but different queue as different user OR they have their own cluster entirely).  To do this, you may set up multiple galaxy sites (i.e. hg clone).  I have each group configured as subdirs on my galaxy domain (e.g. <a href="http://mygalaxy.gov/main">mygalaxy.gov/main</a>, <a href="http://mygalaxy.gov/public">mygalaxy.gov/public</a>, <a href="http://mygalaxy.gov/group1">mygalaxy.gov/group1</a>, etc.).  Each site has (a) different environment variables pointing to its desired cluster (e.g. $SGE_CELL) -- I added these to the run.sh script actually just to make sure i didn&#39;t get confused and (b) universe_wsgi.ini has different job runner definition lines for the tools (specifying queue, resource, project).  Each group is to login to their own site and I used Apache group authentication to enforce this.</div>

<div><br></div><div>A few comments: for these per-group sites, i&#39;m not using the load balancing by separate job and web runners for the group sites, i am not saving job data in the database, and consequently there is no recovery on restart.  since the group sites have a relatively small number of users, this doesn&#39;t seem to be a problem.  Also, i use a hardware-based solution for this (load balancing router), but it hardly seems necessary for the workloads I&#39;ve seen so far (but is necessary for redundancy in case of server hardware failure which may not be an issue for you, depending on your SLA).</div>

<div><br></div><div>I should also mention all group sites use the same postgresql db, so workflows/histories/datasets can be shared across the organization.  However this requires that updates from galaxy-central be done in concert in case there are db schema changes (i have sudo su access to all other groups&#39; galaxy-xx user), but i allow groups to push/pull other changes anytime (groups are not allowed to change galaxy internals/db schema, just add tools and datatypes).</div>

<div><br></div><div>(2) queue selection</div><div><br></div><div>this functionality is already there as of a few months ago.  the fields in the job runner defline/url are:</div><div>0 : sge or pbs</div><div>1 : ??</div><div>

2 : cell (only one allowed per galaxy instance -- that&#39;s why i have multiple group sites)</div><div>3 : queue</div><div>4 : project</div><div>5 : params (e.g. resources)</div><div><br></div><div>so my default job runner looks like this:</div>

<div><br></div><div>sge:///galaxy.q//-b y -V -l medium.c/</div><div><br></div><div>for shorter or longer running jobs (or large ram requirements), I use different -l options (must specify on a per-tool basis).</div><div>
<br>
</div><div>This is a minor inconvenience because when a group adds a tool, their configuration won&#39;t automatically appear in the universe file because it&#39;s not tracked (cannot be, since they have different ports and names). </div>

<div><br></div><div>Hope this helps,</div><div>Ed</div><div><br></div><div><br></div><div><div><div class="gmail_quote">On Mon, Jun 21, 2010 at 6:34 AM, Peter van Heusden <span dir="ltr">&lt;<a href="mailto:pvh@sanbi.ac.za">pvh@sanbi.ac.za</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi there<br>
<br>
At the moment Galaxy&#39;s choice of Sun Grid Engine settings are done on a<br>
per-tool basis - that is, you can define different queues and projects<br>
on a per-tool basis. However, I&#39;ve got two use cases that currently<br>
aren&#39;t supported.<br>
<br>
1) Per-user settings. The SGEJobRunner potentially has access to user<br>
information (via the job.session_id), and while all jobs get run as user<br>
galaxy, per-user settings could be simulated by mapping Galaxy users to<br>
SGE projects. Then the SGE admin can do load-balancing, etc on a<br>
per-project basis. For a site with a relatively small and static set of<br>
users this could work. Alternately you need to map Galaxy users to SGE<br>
users - this is much trickier, requiring elevated privileges and thus<br>
probably a separate job runner daemon.<br>
<br>
2) Queue selection. Again this could be done on a per-tool basis, but<br>
usage patterns don&#39;t always support that. So for example, our site has<br>
two queues - a long running one and a short running one. Certain<br>
resources are reserved for only the short running queue&#39;s usage. How to<br>
select a different queue for jobs raises a bit of a design problem for<br>
me - effectively you&#39;re telling Galaxy &quot;I want to run this workflow, but<br>
with this extra parameter&quot; - its almost like having a &quot;meta parameter&quot;<br>
since clearly you don&#39;t want to have queue selection as an input for any<br>
particular tool.<br>
<br>
So I&#39;d be interested in the Galaxy team&#39;s input as to how best to<br>
address these two use cases.<br>
<br>
Thanks,<br>
Peter<br>
<br>
_______________________________________________<br>
galaxy-dev mailing list<br>
<a href="mailto:galaxy-dev@lists.bx.psu.edu">galaxy-dev@lists.bx.psu.edu</a><br>
<a href="http://lists.bx.psu.edu/listinfo/galaxy-dev" target="_blank">http://lists.bx.psu.edu/listinfo/galaxy-dev</a><br>
</blockquote></div><br></div></div>