Thanks! @Brian please add your ideas and use cases so we can figure out a way how to support this :)
Thanks, Bjoern Am 05.08.2015 um 16:26 schrieb Oksana Korol: > Created issue #74, with reference to this discussion. > > Cheers, > Oksana > > On Wed, Aug 5, 2015 at 9:52 AM, Björn Grüning <bjoern.gruen...@gmail.com> > wrote: > >> Hi Brian, Oksana, >> >> let's move this discussion to github and try to get something done for >> the next+1 release. >> >> 15.07/15.08 or what ever it will be is really close so I would like to >> not rush here. But as soon as we have release this version. We can try >> to get something in :dev that addresses these needs. >> >> What do you think? Can you create an Issue for it? >> Thanks! >> Bjoern >> >> Am 05.08.2015 um 15:39 schrieb Oksana Korol: >>> HI Brian, >>> >>> Thanks for sharing your code. We have just discussed your approach as one >>> possibility of solving our problem, but delayed it as it involved too >> much >>> hacking :). Now that you've done the hacking, we may revisit it. >>> We were also discussing a possibility of creating access groups with >> Galaxy >>> UID and cluster process ID to get around the permissions problem that >> Iyad >>> has described. This would involve extra setup outside Galaxy container, >> but >>> would possibly remove the need to change GID and UID. Will reply when >> we've >>> solidified and tested our approach. >>> >>> Bjorn, >>> >>> I would second Brian on being able to configure Galaxy for different >>> environments. To us that was the primary reason of going the docker way. >> We >>> have considered vagrant, since it seemed like a more mature and more >>> flexible technology for running in production, but went with docker, >>> because Galaxy community supports it. >>> >>> I would personally like to be able to change build-time variables at >> build, >>> since it's more logical, requires less hacks and the build speed is not >> as >>> important to me when building containers for different environments, >> since >>> I'm not going to do that often. I.e.I would still have your lightweight >> way >>> as a default, but allow to change it for those who need it. That said, I >>> would welcome any standardized solution, be it run time or build time. >>> >>> Cheers, >>> Oksana >>> >>> On Wed, Aug 5, 2015 at 4:30 AM, Björn Grüning <bjoern.gruen...@gmail.com >>> >>> wrote: >>> >>>> Hi Brian, >>>> >>>> thanks for you mail! Very appreciated, please see my comments inline. >>>> >>>>>> We only have one cluster, so we will have both test and production >>>>>> environments running on it. I understand that at a minimum we'd need >>>>>> different Galaxy home dir and UID/GID. >>>>> >>>>> >>>>> For our local deployment of Galaxy with Docker, which was inspired by a >>>>> very early version of Björn's docker-galaxy-stable, we use an >> entrypoint >>>>> script to remap the Galaxy user's UID and GID inside the container from >>>>> environment variables GALAXY_UID and GALAXY_GID passed to `docker run`: >>>> >>>> Is this really needed. We could do this in the main image as well, but >>>> currently I haven't seen a compelling usecase for this. The downside is >>>> that we need to do a lot of `chown/chmod` magic during container >> startup. >>>> But I'm totally willing to do so, if this is was the community is >> needed. >>>> >>>> Please also see this latest PR: >>>> https://github.com/bgruening/docker-galaxy-stable/pull/71 >>>> >>>>> >>>> >> https://github.com/fredhutchio/docker-galaxy/blob/aa07c5f684d55499a87e77c62aceda707b63077f/docker-entrypoint.sh#L30 >>>>> >>>>> Just below that, starting at line 42, is an admittedly hacky way of >>>>> relocating the Galaxy directory hierarchy (exported data and/or code) >>>> from >>>>> its container default location /galaxy to another location specified by >>>> the >>>>> GALAXY_ROOT environment variable. It essentially turns the container >> into >>>>> an installer when `--reroot` or `--upgrade` is passed to the entrypoint >>>>> script. `--reroot` copies the container's entire /galaxy hierarchy to >>>>> $GALAXY_ROOT for initializing an instance from the container. >> `--upgrade` >>>>> copies just the container's Galaxy distribution in /galaxy/stable to >>>>> $GALAXY_ROOT/stable (aka $GALAXY_HOME) for upgrading an existing >> instance >>>>> from a more recent image. >>>> >>>> Interesting! >>>> At least for easier upgrading we took a slightly different approach, >>>> described here: >>>> >>>> >> https://github.com/bgruening/docker-galaxy-stable/tree/dev#upgrading-images >>>> >>>> Also we store nowadays many original config files in /etc/galaxy/ to >>>> make the upgrading smoother. >>>> I would be interested in your opinion and if these latest developments >>>> would solve your use-cases. >>>> >>>>> It's definitely nice being able to configure things like this at >> runtime >>>>> for e.g. differentiating between test and production! Would >> functionality >>>>> like this be useful/welcome in docker-galaxy-stable? >>>> >>>> I'm all for it, if this is what is needed by the community. >>>> I would just like to keep the initial startup magic by default as >>>> minimal as possible. >>>> >>>> Thanks a lot for your comments, >>>> Bjoern >>>> >>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> >>>> >>> >>> >>> >> > > > ___________________________________________________________ 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: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
