Galaxy sites usually do all work a compute cluster, with all jobs submitted as a &quot;galaxy&quot; unix user, so there isn&#39;t any &quot;fair-share&quot; accounting between users.<div><br></div><div>Other sysops have created a solution to run jobs as the actual unix user, which may be feasible for an intranet site but is undesirable for a site accessible via the internet due to security reasons.</div>


<div><br></div><div>A simpler and more secure method to enable fair-share is by using projects.</div><div><br></div><div>Here&#39;s a simple scenario and straightforward solution:  Multiple groups in an organization use the same galaxy site and it is desirable to enable fair-share accounting between the groups.  All users in a group consume the same fair-share, which is generally acceptable.</div>


<div><br></div><div>1) configure scheduler with a project for each group, configure each user to use their group&#39;s project by default, and grant galaxy user access to submit jobs to any project; all users should be associated with a project.  There&#39;s a good chance your grid is already configured this way.</div>


<div><br></div><div>2) create a database which maps galaxy user id to a project; i use a cron job to create a standalone sqlite3 db.  since this is site-specific, code is not provided but hints are given below.  Rather than having a separate database, the proj could have been added to the galaxy db, but i sought to minimize my changes.</div>


<div><br></div><div>3) add a snippet of code to drmaa.py&#39;s queue_job method to lookup proj from job_wrapper.user_id and append to jt.nativeSpecification; see below</div><div><br></div><div>Here are the changes required.  It&#39;s small enough that I didn&#39;t do this as a clone/patch.</div>


<div><br></div><div>(1) lib/galaxy/jobs/runners/drmaa.py:</div><div><br></div><div><div> 11 import sqlite3</div></div><div> 12</div><div>...</div><div><div>155         native_spec = self.get_native_spec( runner_url )</div>


<div>156 </div><div>157         # BEGIN ADD USER&#39;S PROJ</div><div>158         if self.app.config.user_proj_map_db is not None:</div><div>159             try:</div><div>160                 conn = sqlite3.connect(self.app.config.user_proj_map_db)</div>


<div>161                 c = conn.cursor()</div><div>162                 c.execute(&#39;SELECT PROJ FROM USER_PROJ WHERE GID=?&#39;, [job_wrapper.user_id])</div><div>163                 row = c.fetchone()</div><div>164                 c.close</div>


<div>165                 native_spec += &#39; -P &#39; + row[0]</div><div>166             except:</div><div>167                 log.debug(&quot;Cannot look up proj of user %s&quot; % job_wrapper.user_id)</div><div>168         # END ADD USER&#39;S PROJ</div>


</div><div><br></div><div>(2) lib/galaxy/config.py: add support for user_proj_map_db variable</div><div><br></div><div>        self.user_proj_map_db = resolve_path( kwargs.get( &quot;user_proj_map_db&quot;, None ), self.root )</div>


<div><br></div><div>(3) universe_wsgi.ini:</div><div><br></div><div>user_proj_map_db = /some/path/to/user_proj_map_db.sqlite</div><div><br></div><div>(4) here&#39;s some suggestions to help get you started on a script to make the sqlite3 db.</div>


<div><br></div><div>a) parse ldap tree example: (to get uid:email)</div><div>ldapsearch -LLL -x -b &#39;ou=aliases,dc=jgi,dc=gov&#39;</div><div><br></div><div>b) parse scheduler config: (to get uid:proj)</div><div>qconf -suserl | /usr/bin/xargs -I &#39;{}&#39; qconf -suser &#39;{}&#39; | egrep &#39;name|default_project&#39;</div>


<div><br></div><div>c) query galaxy db: (to get gid:email)</div><div>select id, email from galaxy_user;</div><div><br></div><div><div>The limitation of this method is that all jobs submitted by a user will always be charged to the same project (which may be okay, depending on how your organization uses projects).  However a user may have access to several projects and may wish to associate some jobs with a particular project.  This could be accomplished by adding an option to the user preferences; a user would chose a project from their available projects and any jobs submitted would have to record their currently chosen project.  Alternatively, histories could be associated with a particular project.  This solution would require significant changes to galaxy, so i haven&#39;t implemented it (and the simple solution works well enough for me).</div>


</div><div><br></div><div>Edward Kirton</div><div>US DOE JGI</div>