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.gruening@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
>>>
>>
>
>
>