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

[2.0] Include in rescue block is included but does not run #13605

Closed
dmsimard opened this issue Dec 18, 2015 · 7 comments
Closed

[2.0] Include in rescue block is included but does not run #13605

dmsimard opened this issue Dec 18, 2015 · 7 comments
Labels
bug This issue/PR relates to a bug. P2 Priority 2 - Issue Blocks Release
Milestone

Comments

@dmsimard
Copy link
Contributor

Issue type: Bug Report
Ansible version: v2.0.0-0.7.rc2
Ansible configuration: Default from pip install
Environment: Fedora, CentOS, locally reproducible

Summary:

Running a command directly in the rescue block works as follows:


---
# roles/tasks/main.yml
tasks:
 - block:
     - debug: msg='I execute normally'
     - command: /bin/false
   rescue:
      - debug:
          msg: "rescuing"

Output:

$ ansible-playbook -vv playbooks/test.yml 
No config file found; using defaults
 [WARNING]: provided hosts list is empty, only localhost is available

1 plays in playbooks/test.yml

PLAY [Include test role] *******************************************************

TASK [test : debug msg=I execute normally] *************************************
ok: [localhost] => {
    "changed": false, 
    "msg": "I execute normally"
}

TASK [test : command] **********************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["/bin/false"], "delta": "0:00:00.001340", "end": "2015-12-18 15:10:27.252622", "failed": true, "rc": 1, "start": "2015-12-18 15:10:27.251282", "stderr": "", "stdout": "", "stdout_lines": [], "warnings": []}

TASK [test : debug msg=rescuing] ***********************************************
ok: [localhost] => {
    "changed": false, 
    "msg": "rescuing"
}

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=1

However, if I move that debug to a rescue.yml file and include it instead, the debug does not run. See following example:


---
# roles/tasks/main.yml
tasks:
 - block:
     - debug: msg='I execute normally'
     - command: /bin/false
   rescue:
     - include: rescue.yml

and


---
# roles/tasks/rescue.yml
- debug:
    msg: "rescuing"

The output of the ansible run with the include is as follows:

$ ansible-playbook -vv playbooks/test.yml 
No config file found; using defaults
 [WARNING]: provided hosts list is empty, only localhost is available

1 plays in playbooks/test.yml

PLAY [Include test role] *******************************************************

TASK [test : debug msg=I execute normally] *************************************
ok: [localhost] => {
    "changed": false, 
    "msg": "I execute normally"
}

TASK [test : command] **********************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["/bin/false"], "delta": "0:00:00.001356", "end": "2015-12-18 15:11:35.071738", "failed": true, "rc": 1, "start": "2015-12-18 15:11:35.070382", "stderr": "", "stdout": "", "stdout_lines": [], "warnings": []}

TASK [test : include] **********************************************************
included: /home/dmsimard/dev/ansible/playbooks/roles/test/tasks/rescue.yml for localhost

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=1
Expectations:

I would expect an included task file to actually run it's contents, in the examples above, this would mean running the debug module inside the rescue.yml file.

@dmsimard
Copy link
Contributor Author

So I thought this could have been related to #13378

I tested with the latest tree but it doesn't change the result.

@bcoca bcoca added this to the v2 milestone Dec 18, 2015
dmsimard pushed a commit to rdo-infra/weirdo that referenced this issue Dec 18, 2015
This commit leverages the new blocks feature from Ansible 2.
When a failure occurs within a tasks block, it will run a rescue
that will:

- Notify the provisioner that CI nodes should be released
- Properly fail

Custom facts are also now set to carry around relevant
variables across different roles.

Note:
- There is quite a bit of duplication in the rescue blocks
  due to includes not being possible right now, see:
  ansible/ansible#13605
- Blocks can probably be moved up to the playbook level
  when this issue gets looked at:
  ansible/ansible#13587

This fixes #1.

Change-Id: I5e4059464291db9f02ec1d2c20989258920f613f
@jimi-c jimi-c added the P2 Priority 2 - Issue Blocks Release label Dec 20, 2015
@jimi-c
Copy link
Member

jimi-c commented Dec 20, 2015

This fixes the bug, however I have not had time to sufficiently test it:

diff --git a/lib/ansible/executor/play_iterator.py b/lib/ansible/executor/play_iterator.py
index 795eed2..d2bb8a3 100644
--- a/lib/ansible/executor/play_iterator.py
+++ b/lib/ansible/executor/play_iterator.py
@@ -397,7 +397,7 @@ class PlayIterator:
 
     def _insert_tasks_into_state(self, state, task_list):
         # if we've failed at all, or if the task list is empty, just return the current state
-        if state.fail_state != self.FAILED_NONE or not task_list:
+        if state.fail_state == self.FAILED_NONE and state.run_state != self.ITERATING_RESCUE or not task_list:
             return state
 
         if state.run_state == self.ITERATING_TASKS:

@dmsimard
Copy link
Contributor Author

@jimi-c If you have a branch/tag with this in, I can swap out rc2 with this to give it a try.

@jimi-c
Copy link
Member

jimi-c commented Dec 20, 2015

@dmsimard I'm about to commit it to devel/stable-2.0

@jimi-c
Copy link
Member

jimi-c commented Dec 20, 2015

Turns out I did have a logic error there, my update patch is:

diff --git a/lib/ansible/executor/play_iterator.py b/lib/ansible/executor/play_iterator.py
index d2bb8a3..534f216 100644
--- a/lib/ansible/executor/play_iterator.py
+++ b/lib/ansible/executor/play_iterator.py
@@ -397,7 +397,7 @@ class PlayIterator:
 
     def _insert_tasks_into_state(self, state, task_list):
         # if we've failed at all, or if the task list is empty, just return the current state
-        if state.fail_state == self.FAILED_NONE and state.run_state != self.ITERATING_RESCUE or not task_list:
+        if state.fail_state != self.FAILED_NONE and state.run_state not in (self.ITERATING_RESCUE, self.ITERATING_ALWAYS) or not task_list:
             return state
 
         if state.run_state == self.ITERATING_TASKS:

I'll push this into devel for now, and merge to stable-2.0 after a bit more testing has been done.

jimi-c added a commit that referenced this issue Dec 20, 2015
Because the fail_state is potentially non-zero in these block sections,
the prior logic led to included tasks not being inserted at all.

Related issue: #13605
dmsimard pushed a commit to rdo-infra/weirdo that referenced this issue Dec 21, 2015
There's a bug fix for includes not working in rescue blocks in
the Ansible devel branch:
ansible/ansible#13605

Change-Id: Ib49b239f255f7cbc6637a288858bd692b2e44876
@dmsimard
Copy link
Contributor Author

So I just tested several roles using includes in rescue blocks (see rdo-infra/weirdo@5c822cf) and it worked well for me. It didn't break anything in the CI.

jimi-c added a commit that referenced this issue Dec 21, 2015
Because the fail_state is potentially non-zero in these block sections,
the prior logic led to included tasks not being inserted at all.

Related issue: #13605
@jimi-c
Copy link
Member

jimi-c commented Dec 21, 2015

@dmsimard I've merged this into stable-2.0 as well now, so we'll go ahead and close this issue.

If you continue seeing any problems related to this issue, or if you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:

Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved.

Thank you!

@jimi-c jimi-c closed this as completed Dec 21, 2015
@ansibot ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 7, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug This issue/PR relates to a bug. P2 Priority 2 - Issue Blocks Release
Projects
None yet
Development

No branches or pull requests

4 participants