Skip to content
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

Draft
wants to merge 15 commits into
base: master
Choose a base branch
from
Draft

Conversation

kysrpex
Copy link
Contributor

@kysrpex kysrpex commented Dec 15, 2023

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.

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.
Copy link
Contributor Author

@kysrpex kysrpex left a 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 use role_name_ as a prefix. Underlines are accepted before the prefix.

@kysrpex
Copy link
Contributor Author

kysrpex commented Dec 15, 2023

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.

@sanjaysrikakulam
Copy link
Member

I will tend to this as soon as I finish with the sn07 playbook.

@mira-miracoli
Copy link
Contributor

Does it make sense at this point to also think about which ansible tasks are now upstream in Galaxy and the ansible-galaxy role?
(the latter I updated two weeks ago after >1 year break)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants