0

I'm working on an Ansible playbook to install some specific Python versions to remote hosts from the deadsnakes repo. The remote machines are on a range of Ubuntu versions, so the Python versions available in the repo differ somewhat from machine to machine.

At present, the playbook task that installs the Python versions looks like this:

- name: Install Python versions
  ansible.builtin.apt:
    name:
      - python3.6
      - python3.6-venv
      - python3.6-dev
      - python3.9
      - python3.9-dev
      - python3.9-venv
    state: latest
    update_cache: true

Which is fine in the main, but for some of the remotes, Python3.6 is not available, which causes the Playbook to fail for those hosts as:

TASK [Install Python versions] ****************************************************************************************
ok: [192.168.1.40]
fatal: [192.168.1.218]: FAILED! => changed=false
  msg: No package matching 'python3.6' is available

There are other subsequent steps in the Playbook that I still want to run, so ideally, I'd like this step to report the issue, but not fail.

I've tried adding ignore_errors: true to the task, and also tried adding a failed_when:... clause, but these simply cause the play to fail for all hosts with an 'Unsupported parameters...' message.

How can I handle this situation? I'm fairly new to Ansible so might be missing something really obvious too.

1 Answer 1

0

Ah. Think I've managed to solve this one myself.

First off, it looks as though I was adding the ignore_errors: true clause at the wrong level ... originally I'd added as:

    - name: Install Python versions
      ansible.builtin.apt:
        name:
          - python3.6
          - python3.6-venv
          - python3.6-dev
          - python3.9
          - python3.9-dev
          - python3.9-venv
        state: latest
        update_cache: true
        ignore_errors: true

which was causing the errors. Instead, indenting ignore_errors as

    - name: Install Python versions
      ansible.builtin.apt:
        name:
          - python3.6
          - python3.6-venv
          - python3.6-dev
          - python3.9
          - python3.9-dev
          - python3.9-venv
        state: latest
        update_cache: true
      ignore_errors: true

actually works. Alternatively, I could wrap the task(s) in a block and handle the exit conditions with a rescue: and always: block.

However, for this particular play, and given that the error is sort of known up-front, I think ignoring it is acceptable here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.