Jean-Baptiste Denis wrote:
> Hello everybody,

Hi Jean-Baptiste,

> i'm in the process to provide Galaxy for multiple team. I've already
> setup a testing instance using the production setup page on the wiki
> (apache + sge) and it works quite well if i'm refearing to the users
> feedback. This setup is typically use for NGS dealing with data on a NFS
> share without uploading them to the instance.
> 
> Why do i need multiple instance ? Maybe i'm not using galaxy correctly.
> Correct me if i'm wrong.
> 
> My goal is to delagate the management of library/datasets to a galaxy
> admin of each team from the beginning : i do NOT want a SINGLE
> independant super admin to manage the access for multiple team, it
> doesn't scale.

Okay, you are correct, then, in needing to do this in seperate
instances.  We'd like for this to eventually become a role instead of
superuser privelege, but I don't know when it'll be implemented.

> The galaxy instance and the underlying "galaxy" system user must access
> to the NGS data on the NFS (v3) share. This means that the galaxy user
> must be in a group that has access to the data. I can delegate the
> process of managing datasets and library to a dedicated galaxy admin.
> This setup is working quite well with the single instance setup. My job
> as a sysadmin is reduced to galaxy setup and maintenance : i'm not
> involved in the library/dataset management.
> 
> The problem with this setup does not work if there is another team with
> data they don't want to share with others (don't blame me on that) : the
> galaxy system user must access the data of the first team AND the second
> team, this means that the galaxy admin of each team could access everything.
> 
> One solution to this problem would be to have an independant galaxy
> super admin with access to everything which manage data access to each
> team. I don't like this solution, like i said, it doesn't scale.
> 
> So, another way to deal with that is to give each team its own galaxy
> instance (each running with a specific system galaxy user) with a
> dedicated galaxy admin. Two possibility :
> 
> - N galaxy tree, each with a different tuned universe_wsgi.ini init file
> (dedicated path, port, database, etc...). The problem here is on the
> sysadmin side : the update process effort must be repeated N times.
> 
> - A unique galaxy tree, and N tuned (dedicated path, port, database,
> etc...) universe_wsgi.ini files. This seems the best to me but i need to
> know if galaxy internals can managed that kind of setup ?

The latter should work fine, but you may have problems if users of one
Galaxy instance want to share with users of another Galaxy instance.

Hope this helps, and sorry for the long delay in response.

--nate

> 
> What do you think ? Any inputs, remarks or advices are welcome !
> 
> Regards,
> 
> Jean-Baptiste
> ___________________________________________________________
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
> 
>   http://lists.bx.psu.edu/
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Reply via email to