Avoid using ansible_failed_task in rescue blocks #88
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 6, 2020
yizhanglinux
approved these changes
May 7, 2020
ansible_failed_task can contain unexpanded Jinja2 templates with variable references that were valid when the task failed, but not valid anymore when using the variable in the rescue block. In this case the problem is with task names (.name) that contain references to storage_provider. Unfortunately this completely prevents using ansible_failed_task even if not using the problematic attribute. Other attribute could have been used if this were not the case, like .tags, but until ansible/ansible#49942 is fixed, it is better to avoid using ansible_failed_task and use the only other special variable describing the failed task: ansible_failed_result. Eliminate the previous workaround to set storage_provider on the tasks that expand ansible_failed_task and use ansible_failed_result with a special value of msg instead. This has a disadvantage of having to use a special msg with the fail module, while usually it is just a free-form message. The fail module does not set another attribute of the result that could be used though, and it is cleaner than the previous workaround.
pcahyna
force-pushed
the
eliminate-task-name-workaround
branch
from
bbf1f2e to
787f00c
Compare
|
Note to myself: this trick should be added to oasis-roles/meta_standards#19 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ansible_failed_taskcan contain unexpanded Jinja2 templates with variable references that were valid when the task failed, but not valid anymore when using the variable in therescueblock. In this case the problem is with task names (.name) that contain references tostorage_provider. Unfortunately this completely prevents usingansible_failed_taskeven if not using the problematic attribute. Other attribute could have been used if this were not the case, like.tags, but until ansible/ansible#49942 is fixed, it is better to avoid usingansible_failed_taskand use the only other special variable describing the failed task:ansible_failed_result.Eliminate the previous workaround to set storage_provider on the tasks that expand
ansible_failed_taskand useansible_failed_resultwith a special value ofmsginstead. This has a disadvantage of having to use a specialmsgwith thefailmodule, while usually it is just a free-form message. Thefailmodule does not set another attribute of the result that could be used though, and it is cleaner than the previous workaround.