-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Galaxy servers playbook #1053
base: master
Are you sure you want to change the base?
Galaxy servers playbook #1053
Conversation
To realize a set-up with two redundant Galaxy servers, it makes sense to start from the existing playbook for our single Galaxy server so that the Git history for the file is kept intact.
A search within the project files reveals that no references to this group name exist.
…roup vars file I have not checked the correctness of the move, we may have to move a few variables back later. In the group vars file, organize the variables in blocks and add a comment before each block stating which role owns them.
…k applies from the group `sn06` to the group `galaxy` Exclude `sn06.galaxyproject.eu` for the time being.
…rently It is a time sink and very annoying to have to re-run playbooks until no more "command not found" errors appear because of forgetting to install role dependencies (meaning system packages, not other roles). See issue galaxyproject/ansible-gxadmin#3 for an example of someone complaining about this recurring problem. I thought of creating a role called "usegalaxy_eu.packages" that alleviates this problem. The idea is to define a list of the packages each role depends on in group_vars/all.yml (see the example below), then have the role check what other roles are imported in a play and install the corresponding dependencies. ```yaml # Ansible role package dependencies (managed by usegalaxy_eu.packages) packages: usegalaxy_eu.handy.os_setup: - findutils galaxyproject.gxadmin: - git - make - "postgresql{{ '-client' if ansible_os_family == 'Debian' }}" usegalaxy-eu.bashrc: - python3-psycopg2 - python3-pyyaml ``` The idea to create this role stems just from stumbling upon the problem. See galaxyproject/ansible-gxadmin#11 for an additional discussion on the topic.
The custom Pulsar build was meant to be used during the HTCondor migration to have two embedded pulsar runners, each submitting jobs to a different HTCondor cluster. For a new Galaxy server set up from scratch, the migration is formally complete and only one pulsar embedded runner is needed. Thus, this patched version is not needed anymore.
The HTCondor clusters playbook is now responsible for setting the node up as a submitter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kysrpex wrote on commit 9c8429d:
add a comment before each block stating which role owns them
The ansible-lint developers seem to have come to the same conclusion that knowing which role owns each variable may be helpful, as they included a rule to check it.
var-naming[no-role-prefix]
: Variables names from within roles should userole_name_
as a prefix. Underlines are accepted before the prefix.
We need to reconcile the history of sn07.yml (merge and solve conflicts in a way that makes sense) with this playbook. I have started to do this (but not committed anything) and this is difficult, because sn07.yml is more than a year old and both sn06.yml and sn07.yml have diverged separately. @sanjaysrikakulam, @mira-miracoli I see from the histories of sn06.yml and sn07.yml that they have mainly been modified by both of you. Please if you can, try to think of what is missing or should not be in galaxy.yml. Remember that galaxy.yml stems from sn06.yml, so it has everything that sn06.yml has. As a suggestion for a starting point, you may diff the latest version of sn06.yml and the latest version of sn07.yml. The point of having one playbook instead of two is precisely to prevent this from happening. Take into account that the longer all this takes, the bigger the risk of playbooks diverging again becomes. Then we would have 3 divergent playbooks! EDIT: the same applies to group_vars/sn06.yml and group_vars/sn07.yml. |
I will tend to this as soon as I finish with the |
Does it make sense at this point to also think about which ansible tasks are now upstream in Galaxy and the ansible-galaxy role? |
Closes usegalaxy-eu/issues#352.
This is a work in process, all contents of the modified files are subject to change, non-definitive, and not necessarily correct (in the sense of working properly). Broken code is allowed, although very broken code is discouraged.