On Jan 23, 2012, at 11:09 AM, Nate Coraor wrote:
> Sure, it's on the "todo" list. Ping me again in a year. ;)
Now in a ticket:
https://bitbucket.org/galaxy/galaxy-central/issue/709/add-more-control-over-where-jobs-run
>
> --nate
>
> On Jan 20, 2012, at 7:33 PM, Edward Kirton wrote:
>
>> Gre
Sure, it's on the "todo" list. Ping me again in a year. ;)
--nate
On Jan 20, 2012, at 7:33 PM, Edward Kirton wrote:
> Great idea, Nate (hint! hint!).
>
> On Thu, Jan 19, 2012 at 10:27 AM, Nate Coraor wrote:
>> Hey Ed,
>>
>> This is a neat approach. You could possibly also do this in the Gal
I really want this for Torque/Moab where the native spec flag is -A
Sent from my iPhone
On Jan 20, 2012, at 7:34 PM, "Edward Kirton" wrote:
> Great idea, Nate (hint! hint!).
>
> On Thu, Jan 19, 2012 at 10:27 AM, Nate Coraor wrote:
>> Hey Ed,
>>
>> This is a neat approach. You could possibly
Great idea, Nate (hint! hint!).
On Thu, Jan 19, 2012 at 10:27 AM, Nate Coraor wrote:
> Hey Ed,
>
> This is a neat approach. You could possibly also do this in the Galaxy
> database by associating users and groups with roles that match project names.
> A select list or history default that all
Hey Ed,
This is a neat approach. You could possibly also do this in the Galaxy
database by associating users and groups with roles that match project names.
A select list or history default that allowed users to select their "current"
project/role would remove the single-project-per-user limi
correction: i didn't adequately test what happens if the user_proj_map_db
was not defined in the universe file; here's the changes:
157 # BEGIN ADD USER'S PROJ
158 try:
159 conn = sqlite3.connect(self.app.config.user_proj_map_db)
160 c = conn.cursor()
161
Galaxy sites usually do all work a compute cluster, with all jobs submitted
as a "galaxy" unix user, so there isn't any "fair-share" accounting between
users.
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
