Frequently Asked Questions


Define once, reference many times

Using variables, either by defining them ahead of time, or simply accessing them via existing data structures that have been defined, e.g.:

# defining a variable that gets reused is great!
galaxy_user: galaxy

# Re-using the galaxy_config_dir variable saves time and ensures everything
# is in sync!
datatypes_config_file: "/datatypes_conf.xml"

# and now we can re-use ""
# in other places!

- src: templates/galaxy/config/datatypes_conf.xml
dest: ""

Practices like those shown above help to avoid problems caused when paths are defined differently in multiple places. The datatypes config file will be copied to the same path as Galaxy is configured to find it in, because that path is only defined in one place. Everything else is a reference to the original definition! If you ever need to update that definition, everything else will be updated accordingly.

Error: "skipping: no hosts matched"

There can be multiple reasons this happens, so we’ll step through all of them.We’ll start by assuming you’re running the command

ansible-playbook galaxy.yml

The following things can cause issues:

  1. Within your galaxy.yml, you’ve referred to a host group that doesn’t exist or is misspelled. Check the hosts: galaxyservers to ensure it matches the host group defined in the hosts file.
  2. Vice-versa, the group in your hosts file should match the hosts selected in the playbook, galaxy.yml.
  3. If neither of these are the issue, it’s possible Ansible doesn’t know to check the hosts file for the inventory. Make sure you’ve specified inventory = hosts in your ansible.cfg.

Galaxy Admin Training Path

Comment: Galaxy Admin Training Path

The yearly Galaxy Admin Training follows a specific ordering of tutorials. Use this timeline to help keep track of where you are in Galaxy Admin Training.

  1. Step 1 ansible-galaxy
  2. Step 2 tus
  3. Step 3 cvmfs
  4. Step 4 singularity
  5. Step 5 tool-management
  6. Step 6 data-library
  7. Step 7 connect-to-compute-cluster
  8. Step 8 job-destinations
  9. Step 9 pulsar
  10. Step 10 gxadmin
  11. Step 11 monitoring
  12. Step 12 tiaas
  13. Step 13 reports
  14. Step 14 ftp

How do I know what I can do with a role? What variables are available?

You don’t. There is no standard way for reporting this, but well written roles by trusted authors (e.g. geerlingguy, galaxyproject) do it properly and write all of the variables in the README file of the repository. We try to pick sensible roles for you in this course, but, in real life it may not be that simple.

So, definitely check there first, but if they aren’t there, then you’ll need to read through defaults/ and tasks/ and templates/ to figure out what the role does and how you can control and modify it to accomplish your goals.

Is YAML sensitive to True/true/False/false

By this reference, YAML doesn’t really care:

{ Y, true, Yes, ON   }    : Boolean true
{ n, FALSE, No, off } : Boolean false

Operating system compatibility

These Ansible roles and training materials were last tested on Centos 7 and Ubuntu 18.04, but will probably work on other RHEL and Debian variants.

The roles that are used in these training are currently used by usegalaxy.*, and other, servers in maintaining their infrastructure. (US, EU, both are running CentOS 7)

If you have an issue running these trainings on your OS flavour, please report the issue in the training material and we can see if it is possible to solve.

Running Ansible on your remote machine

It is possible to have ansible installed on the remote machine and run it there, not just from your local machine connecting to the remote machine.

Your hosts file will need to use localhost, and whenever you run playbooks with ansible-playbook -i hosts playbook.yml, you will need to add -c local to your command.

Be certain that the playbook that you’re writing on the remote machine is stored somewhere safe, like your user home directory, or backed up on your local machine. The cloud can be unreliable and things can disappear at any time.

Variable connection

When the playbook runs, as part of the setup, it collects any variables that are set. For a playbook affecting a group of hosts named my_hosts, it checks many different places for variables, including “group_vars/my_hosts.yml”. If there are variables there, they’re added to the collection of current variables. It also checks “group_vars/all.yml” (for the built-in host group all). There is a precedence order, but then these variables are available for roles and tasks to consume.

What if you forget `--diff`?

If you forget to use --diff, it is not easy to see what has changed. Some modules like the copy and template modules have a backup option. If you set this option, then it will keep a backup copy next to the destination file.

However, most modules do not have such an option, so if you want to know what changes, always use --diff.

What is the difference between the roles with `role:` prefix and without?

The bare role name is just simplified syntax for the roles, you could equally specifiy role: <name> every time but it’s only necessary if you want to set additional variables like become_user


How to read a Diff

If you haven’t worked with diffs before, this can be something quite new or different.

If we have two files, let’s say a grocery list, in two files. We’ll call them ‘a’ and ‘b’.

$ cat old
$ cat new

We can see that they have some different entries. We’ve removed 🍒 because they’re awful, and replaced them with an 🍍

Diff lets us compare these files

$ diff old new
< 🍒
> 🍍

Here we see that 🍒 is only in a, and 🍍 is only in b. But otherwise the files are identical.

There are a couple different formats to diffs, one is the ‘unified diff’

$ diff -U2 old new
--- old 2022-02-16 14:06:19.697132568 +0100
+++ new 2022-02-16 14:06:36.340962616 +0100
@@ -3,4 +3,4 @@

This is basically what you see in the training materials which gives you a lot of context about the changes:

  • --- old is the ‘old’ file in our view
  • +++ new is the ‘new’ file
  • @@ these lines tell us where the change occurs and how many lines are added or removed.
  • Lines starting with a - are removed from our ‘new’ file
  • Lines with a + have been added.

So when you go to apply these diffs to your files in the training:

  1. Ignore the header
  2. Remove lines starting with - from your file
  3. Add lines starting with + to your file

The other lines (🍊/🍋 and 🥑) above just provide “context”, they help you know where a change belongs in a file, but should not be edited when you’re making the above change. Given the above diff, you would find a line with a 🍒, and replace it with a 🍍

Added & Removed Lines

Removals are very easy to spot, we just have removed lines

--- old	2022-02-16 14:06:19.697132568 +0100
+++ new 2022-02-16 14:10:14.370722802 +0100
@@ -4,3 +4,2 @@

And additions likewise are very easy, just add a new line, between the other lines in your file.

--- old	2022-02-16 14:06:19.697132568 +0100
+++ new 2022-02-16 14:11:11.422135393 +0100
@@ -1,3 +1,4 @@

Completely new files

Completely new files look a bit different, there the “old” file is /dev/null, the empty file in a Linux machine.

$ diff -U2 /dev/null old
--- /dev/null 2022-02-15 11:47:16.100000270 +0100
+++ old 2022-02-16 14:06:19.697132568 +0100
@@ -0,0 +1,6 @@

And removed files are similar, except with the new file being /dev/null

--- old	2022-02-16 14:06:19.697132568 +0100
+++ /dev/null 2022-02-15 11:47:16.100000270 +0100
@@ -1,6 +0,0 @@


How many mules?

Start with 2 and add more as needed. If you notice that your jobs seem to inexplicably sit for a long time before being dispatched to the cluster, or after they have finished on the cluster, you may need additional handlers.

Galaxy admin interface

Install tools via the Admin UI

  1. Open Galaxy in your browser and type `` in the tool search box on the left. If “” is among the search results, you can skip the following steps.
  2. Access the Admin menu from the top bar (you need to be logged-in with an email specified in the admin_users setting)
  3. Click “Install and Uninstall”, which can be found on the left, under “Tool Management”
  4. Enter `` in the search interface
  5. Click on the first hit, having devteam as owner
  6. Click the “Install” button for the latest revision
  7. Enter “” as the target section and click “OK”.


Got lost along the way?

Comment: Got lost along the way?

If you missed any steps, you can compare against the reference files, or see what changed since the previous tutorial.

If you’re using git to track your progress, remember to add your changes and commit with a good commit message!

Still have questions?
Gitter Chat Support
Galaxy Help Forum