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.

Sign up for GitHub

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

Fix fatal errors in GxIT and ansible tutorials #4370

Merged
merged 4 commits into from
Oct 3, 2023
Merged

Fix fatal errors in GxIT and ansible tutorials #4370

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f99e2a1
Fix errors in GxIT and ansible tutorials
tuncK Oct 3, 2023
01e8a49
typo fixed
tuncK Oct 3, 2023
1b9f010
revert galaxy version upgrades
tuncK Oct 3, 2023
94f77d8
Add cross-links between SSL boxes
hexylena Oct 3, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions topics/admin/tutorials/ansible-galaxy/tutorial.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -275,7 +275,7 @@ We have codified all of the dependencies you will need into a YAML file that `an
> @@ -0,0 +1,13 @@
> +# Galaxy, Postgres, Nginx
> +- src: galaxyproject.galaxy
> + version: 0.10.14
> + version: 0.10.15
tuncK marked this conversation as resolved.
Show resolved Hide resolved
> +- src: galaxyproject.nginx
> + version: 0.7.1
> +- src: galaxyproject.postgresql
Expand Down Expand Up @@ -894,10 +894,10 @@ The configuration is quite simple thanks to the many sensible defaults that are
> `galaxy_layout` | `root-dir` | This enables the `galaxy_root` Galaxy deployment layout: all of the code, configuration, tools, and mutable-data (like caches, location files, etc.) folders will live by default beneath `galaxy_root`. User data is stored under `file_path`, a variable we will set later.
> `galaxy_root` | `/srv/galaxy` | This is the root of the Galaxy deployment.
> `galaxy_user` | `{name: "{{ galaxy_user_name }}", shell: /bin/bash}` | The user that Galaxy will run as.
> `galaxy_commit_id` | `release_23.0` | The git reference to check out, which in this case is the branch for Galaxy Release 23.0
> `galaxy_commit_id` | `release_23.1` | The git reference to check out, which in this case is the branch for Galaxy Release 23.1
hexylena marked this conversation as resolved.
Show resolved Hide resolved
> `galaxy_force_checkout` | `true` | If we make any modifications to the Galaxy codebase, they will be removed. This way we know we're getting an unmodified Galaxy and no one has made any unexpected changes to the codebase.
> `miniconda_prefix` | {% raw %}`"{{ galaxy_tool_dependency_dir }}/_conda"`{% endraw %} | We will manually install conda as well. Normally Galaxy will attempt to auto-install this, but since we will set up a production-ready instance with multiple handlers, there is the chance that they can become deadlocked.
> `miniconda_version` | `4.12.0` | Install a specific miniconda version, the latest one at the time of writing that was tested and working.
> `miniconda_version` | `23.9` | Install a specific miniconda version, the latest one at the time of writing that was tested and working.
> `miniconda_channels` ` | `['conda-forge', 'defaults']` | Use the community-maintained conda-forge channel in addition to the standard defaults channel of Conda.
>
> > <tip-title>Different Galaxy Releases!</tip-title>
Expand All @@ -920,10 +920,10 @@ The configuration is quite simple thanks to the many sensible defaults that are
> +galaxy_layout: root-dir
> +galaxy_root: /srv/galaxy
> +galaxy_user: {name: "{{ galaxy_user_name }}", shell: /bin/bash}
> +galaxy_commit_id: release_23.0
> +galaxy_commit_id: release_23.1
> +galaxy_force_checkout: true
> +miniconda_prefix: "{{ galaxy_tool_dependency_dir }}/_conda"
> +miniconda_version: 4.12.0
> +miniconda_version: 23.9
> +miniconda_channels: ['conda-forge', 'defaults']
> {% endraw %}
> ```
Expand Down Expand Up @@ -956,7 +956,7 @@ The configuration is quite simple thanks to the many sensible defaults that are
> +++ b/group_vars/galaxyservers.yml
> @@ -10,3 +10,17 @@ galaxy_force_checkout: true
> miniconda_prefix: "{{ galaxy_tool_dependency_dir }}/_conda"
> miniconda_version: 4.12.0
> miniconda_version: 23.9
> miniconda_channels: ['conda-forge', 'defaults']
> +
> +galaxy_config:
Expand Down Expand Up @@ -2082,7 +2082,7 @@ For this, we will use NGINX (pronounced "engine X" /ˌɛndʒɪnˈɛks/ EN-jin-EK
>
> > <details-title>Running this tutorial <i>without</i> SSL</details-title>
> >
> > In your `galaxy.j2` in the above step, you should change the `listen` parameter:
> > Ignore the https redirection by omitting `templates/nginx/redirect-ssl.j2`. In your `galaxy.j2` in the above step, you should change the `listen` parameter:
hexylena marked this conversation as resolved.
Show resolved Hide resolved
> >
> > {% raw %}
> > ```diff
Expand Down Expand Up @@ -2175,7 +2175,7 @@ In order to be the administrator user, you will need to register an account with

## Job Configuration

One of the most important configuration files for a large Galaxy server is the job configuration. This tells Galaxy where to run all of the jobs that users execute. If Galaxy can't find a job conf file or no job configuration has been specified inline in the `galaxy.yml` file, it will use a simple default configuration where all jobs are run on the Galaxy server and are handled by the web serving process, rather than the job handler(s). Galaxy's job running system is highly configurable, the full range of configuration can be found in the sample job configuration file, [`job_conf.sample.yml`](https://github.com/galaxyproject/galaxy/blob/release_23.0/lib/galaxy/config/sample/job_conf.sample.yml).
One of the most important configuration files for a large Galaxy server is the job configuration. This tells Galaxy where to run all of the jobs that users execute. If Galaxy can't find a job conf file or no job configuration has been specified inline in the `galaxy.yml` file, it will use a simple default configuration where all jobs are run on the Galaxy server and are handled by the web serving process, rather than the job handler(s). Galaxy's job running system is highly configurable, the full range of configuration can be found in the sample job configuration file, [`job_conf.sample.yml`](https://github.com/galaxyproject/galaxy/blob/release_23.1/lib/galaxy/config/sample/job_conf.sample.yml).

The job configuration allows Galaxy to run jobs in multiple locations using a variety of different mechanisms. Some of these mechanisms include:

Expand Down Expand Up @@ -2232,7 +2232,7 @@ Finally, we have explicitly mapped the tool `bwa` to run in the `local_env` envi
> --- a/group_vars/galaxyservers.yml
> +++ b/group_vars/galaxyservers.yml
> @@ -11,6 +11,24 @@ miniconda_prefix: "{{ galaxy_tool_dependency_dir }}/_conda"
> miniconda_version: 4.12.0
> miniconda_version: 23.9
> miniconda_channels: ['conda-forge', 'defaults']
>
> +# Galaxy Job Configuration
Expand Down Expand Up @@ -2464,7 +2464,7 @@ The time required to maintain a production Galaxy instance depends on the number

## Keeping Galaxy Updated

If you have set your `galaxy_commit_id` group variable to a branch name like `release_23.0`, then all you need to do to keep Galaxy up to date (e.g. for security and bug fixes) is to run the playbook regularly. The `git` module in Ansible checks if you are on the latest commit of a given branch, and will update the clone of the repository if it is not.
If you have set your `galaxy_commit_id` group variable to a branch name like `release_23.1`, then all you need to do to keep Galaxy up to date (e.g. for security and bug fixes) is to run the playbook regularly. The `git` module in Ansible checks if you are on the latest commit of a given branch, and will update the clone of the repository if it is not.

## Upgrading Galaxy (Optional)

Expand Down
Loading