Answers: <p>Ah.  Think I've managed to solve this one myself.</p>
  <p>First off, it looks as though I was adding the <code>ignore_errors: true</code> clause at the wrong level ... originally I'd added as:</p>
  <pre class="lang-yaml prettyprint-override"><code>    - 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
  </code></pre>
  <p>which was causing the errors.  Instead, indenting <code>ignore_errors</code> as</p>
  <pre class="lang-yaml prettyprint-override"><code>    - 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
  </code></pre>
  <p>actually works.  Alternatively, I could wrap the task(s) in a block and handle the exit conditions with a <code>rescue:</code> and <code>always:</code> block.</p>
  <p>However, for this particular play, and given that the error is sort of known up-front, I think ignoring it is acceptable here.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-06-12T13:53:35.163Z
Answers: 2024-06-12T16:18:58.247Z
Answers: 2024-06-12T16:18:58.247Z
Answers: Mark Edwards
Body: <p>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.</p>
  <p>At present, the playbook task that installs the Python versions looks like this:</p>
  <pre class="lang-yaml prettyprint-override"><code>- 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
  </code></pre>
  <p>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:</p>
  <pre><code>TASK [Install Python versions] ****************************************************************************************
  ok: [192.168.1.40]
  fatal: [192.168.1.218]: FAILED! =&gt; changed=false
    msg: No package matching 'python3.6' is available
  </code></pre>
  <p>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 <em>not</em> fail.</p>
  <p>I've tried adding <code>ignore_errors: true</code> to the task, and also tried adding a <code>failed_when:...</code> clause, but these simply cause the play to fail for all hosts with an 'Unsupported parameters...' message.</p>
  <p>How can I handle this situation? I'm fairly new to Ansible so might be missing something <em>really</em> obvious too.</p>
  
Tags: <ansible><ubuntu>
Title: How to ignore playbook failure when package missing in apt list?
UserDisplayName: Mark Edwards
ThreadText: # How to ignore playbook failure when package missing in apt list?
  
  (Asked by: username_0 on 2024-06-12)
  
  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:
  
  ```yaml
  - 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.
  
  **Tags:** ansible, ubuntu
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2024-06-12. Score: 0 | Accepted answer
  
  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:
  
  ```yaml
      - 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
  
  ```yaml
      - 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.
  
  
  ---
  
  