# Galaxy
galaxy_create_user: true # False by default, as e.g. you might have a 'galaxy' user provided by LDAP or AD.
galaxy_separate_privileges: true # Best practices for security, configuration is owned by 'root' (or a different user) than the processes
galaxy_manage_paths: true # False by default as your administrator might e.g. have root_squash enabled on NFS. Here we can create the directories so it's fine.
galaxy_layout: root-dir
galaxy_root: /srv/galaxy
galaxy_user: {name: "{{ galaxy_user_name }}", shell: /bin/bash}
galaxy_commit_id: release_23.0
galaxy_force_checkout: true
miniconda_prefix: "{{ galaxy_tool_dependency_dir }}/_conda"
miniconda_version: 23.9
miniconda_channels: ['conda-forge', 'defaults']
The client build is skipped to save a little bit of time during my tests. Actually I run the full GTN galaxy installation with ansible and in the end I get the handlers skipped.
This is probably due to the fact that gravity_22.05 and gravity_23.0 handlers has the same names, while it should be unique: “Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one loaded into the play can be notified and executed, effectively shadowing all of the previous handlers with the same name.” (from https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html#naming-handlers).
Indeed changing the names causes handlers 22.05 being skipped and those 23.0 correctly run.
I don’t know if this is wanted or, more probably, I’ve missed something.
Marco
Hi, I was running the galaxyproject.galaxy role. After few tries I still get the handlers for starting galaxy skipped:
Minimal step to reproduce it:
group_vars/galaxy.yml
Playbook:
Role: galaxyproject.galaxy,0.10.14
The client build is skipped to save a little bit of time during my tests. Actually I run the full GTN galaxy installation with ansible and in the end I get the handlers skipped.
This is probably due to the fact that gravity_22.05 and gravity_23.0 handlers has the same names, while it should be unique: “Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one loaded into the play can be notified and executed, effectively shadowing all of the previous handlers with the same name.” (from https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html#naming-handlers).
Indeed changing the names causes handlers 22.05 being skipped and those 23.0 correctly run.
I don’t know if this is wanted or, more probably, I’ve missed something. Marco