Yes, both configuration flavours are currently allowed. You would need to find the correct YAML part. E.g. here: galaxy/lib/galaxy/config/sample/job_conf.sample.yml at dev · galaxyproject/galaxy · GitHub
I’ve tried multiple permutations of the “–add-host” arg in the job_conf.yml, but whatever I try, it seems to prevent my IT from actually starting. It stays stuck on the “Waiting for… to become available”
docker_run_extra_arguments: --add-host localhost:host-gateway --platform linux/amd64
I’m not sure where to go from here. I was really hoping there was an example of an IT, in a Docker container, in a local Galaxy instance, which successfully used the put/get, i.e., could correctly access the env vars in the IT’s .xml.
Sanity check: am I correct in thinking those env vars do not need to change?
In spite of feeling like I was close to resolving everything necessary to use the put/get in my IT - and test locally, maybe I do indeed need to skip the local testing and just request installs in a production Galaxy instance.
There are such ITs, Juypter Notebook, and RStudio, you can test it on EU for example.
You need quotes afaik:
docker_run_extra_arguments: "--add-host localhost:host-gateway --platform linux/amd64"
Please share your entire job_conf file.
I was also told that IT work in this one GitHub - bgruening/docker-galaxy: 🐋📊📚 Docker Images tracking the stable Galaxy releases. - but I don’t want to sent you into this rabbit whole.
Adding the quotes causes the infinite “Waiting…” state. Removing the quotes allows the IT to start, almost immediately. But it still gives the “Could not connect to galaxy instance” when I attempt a “put”.
Here is a full example file: galaxy/config/job_conf.yml.interactivetools at 5d197246ff7d9718f9a7cc645663a2b087d4d872 · galaxyproject/galaxy · GitHub
What you can try is to start everything but then dive into the container, try to ping your host Galaxy. Execute the get/put from inside the container and try if you see more debug errors. I would recommend to do this with Jupyter where you know it should be working.
In the job_conf.yml, do I keep this:
execution:
default: docker_dispatch
or should it change to default: docker_local
I will just begin experimenting… Thanks for your patience.
In the .yml template that you linked to, it has:
#docker_run_extra_arguments: --add-host localhost:host-gateway
When I uncomment that line and run, I’m once again stuck in the “Waiting…” state for the IT. But if I append --platform linux/amd64
to that line and re-run, the IT enters the “Open…” state almost immediately. And a put
results in the usual Exception: Could not connect to a galaxy instance
I’ve continued to try several attempts - each trying to tweak some small thing; confirmed my API key matches, and I’ve examined log files, e.g.,
gunicorn.log:
galaxy.tool_util.output_checker INFO 2025-05-23 18:30:59,341 [pN:main.1,p:20384,tN:LocalRunner.work_thread-2] Job error detected, failing job. Reasons are [{‘type’: ‘exit_code’, ‘desc’: ‘Fatal error: Exit code 12 ()’, ‘exit_code’: 12, ‘code_desc’: ‘’, ‘error_level’: 3}]
yet I continue to get the “Could not connect to galaxy instance” when I attempt a “put” from my IT.
How can I find out where that “Could not connect…” msg is coming from. I assumed it was in the bioblend code (or Galaxy itself), but I could not find it doing a global search.
Is there something I’m missing about having Galaxy start my IT/container that drops me into a bash shell, from which I could try to ping the Galaxy host?
Here’s is my entire job_conf.yml:
(base) heiland@yoga:~/dev/galaxy-24.2.3$ more config/job_conf.yml
## A sample job config for InteractiveTools using local runner. ##
runners:
local:
load: galaxy.jobs.runners.local:LocalJobRunner
workers: 4
# Uncomment if dynamic handlers are defined in "gravity:handlers" section in galaxy.yml
#
#handling:
# assign:
# - db-skip-locked
execution:
default: docker_dispatch
environments:
local:
runner: local
docker_local:
runner: local
docker_enabled: true
#docker_volumes: $defaults,/mnt/galaxyData/libraries:ro,/mnt/galaxyData/indices:ro
#docker_volumes_from: parent_container_name
#docker_memory: 24G
#docker_sudo: false
#docker_sudo_cmd: /usr/bin/sudo -extra_param
#docker_net: bridge
#docker_auto_rm: true
#docker_set_user: $UID
docker_set_user:
# InteractiveTools do need real hostnames or URLs to work - simply specifying IPs will not work.
# If you develop interactive tools on your 'localhost' and don't have a proper domain name
# you need to tell all Docker containers a hostname where Galaxy is running.
# This can be done via the add-host parameter during the `docker run` command.
# 'localhost' here is an arbitrary hostname that matches the IP address of your
# Galaxy host. Make sure this hostname ('localhost') is also set in your galaxy.yml file, e.g.
# `galaxy_infrastructure_url: http://localhost:8080`.
#docker_run_extra_arguments: add-host localhost:host-gateway
docker_run_extra_arguments: --add-host localhost:host-gateway --platform linux/amd64
#docker_cmd: /usr/local/custom_docker/docker
#docker_host:
#docker_container_id_override: busybox:1.36.1-glibc
#docker_default_container_id: busybox:1.36.1-glibc
#require_container: true
#container_monitor: true
#container_monitor_result: file
#container_monitor_command: python /path/to/galaxy/lib/galaxy_ext/container_monitor/monitor.py
#container_monitor_get_ip_method: null
#container_resolvers_config_file: null
#container_resolvers:
docker_dispatch:
runner: dynamic
type: docker_dispatch
docker_destination_id: docker_local
default_destination_id: local