Ansible troubleshooting - Error 104: Deprecated Bare Vars

Introduction

Ansible, the popular open-source automation platform, provides a straightforward and efficient way to automate tasks, manage configurations, and orchestrate processes. However, as with any tool, there are best practices to follow and potential pitfalls to avoid. In this article, we will delve into Ansible Error 104, “Deprecated Bare Vars”, which is a rule in Ansible-Lint designed to identify potentially confusing expressions where it’s unclear whether a variable or string should be used. We will explore this error, understand its implications, and learn how to write clean, maintainable Ansible code that adheres to best practices.

The Problem: Deprecated Bare Vars

Ansible Error 104, known as “Deprecated Bare Vars”, is a valuable rule designed to maintain code clarity and consistency. This rule points out situations where it is unclear whether a given expression should be interpreted as a variable or a string. To address this, Ansible encourages users to either use the full variable syntax or convert the expression into a list of strings.

Problematic Code Example:

---
- ansible.builtin.debug:
    msg: "{{ item }}"
  with_items: foo # <-- deprecated-bare-vars

In the code above, the variable “foo” is being referenced without any clear indication of whether it’s a variable or a string. This ambiguity can lead to confusion and potential issues down the line.

Output:

WARNING  Listing 2 violation(s) that are fatal
schema[playbook]: $[0].tasks[0].with_items 'production' does not match '^\\{[\\{%](.|[\r\n])*[\\}%]\\}$'
104.yml:1  Returned errors will not include exact line numbers, but they will mention
the schema name being used as a tag, like ``schema[playbook]``,
``schema[tasks]``.

This rule is not skippable and stops further processing of the file.

If incorrect schema was picked, you might want to either:

* move the file to standard location, so its file is detected correctly.
* use ``kinds:`` option in linter config to help it pick correct file type.


deprecated-bare-vars: Possible bare variable 'production' used in a 'with_items' loop. You should use the full variable syntax ('{{ production }}') or convert it to a list if that is not really a variable.
104.yml:7 Task/Handler: Ensure a task runs only in the production environment

Read documentation for instructions on how to ignore specific rule violations.

                 Rule Violation Summary                  
 count tag                  profile rule associated tags 
     1 deprecated-bare-vars basic   deprecations         
     1 schema[playbook]     basic   core                 

Failed: 2 failure(s), 0 warning(s) on 1 files. Last profile that met the validation criteria was 'min'.

Correcting the Code

To resolve Ansible Error 104 and improve code clarity, it’s essential to provide explicit indications of whether “foo”` is a variable or a string. This can be achieved by using one of the following approaches:

1. If “foo” is not a variable:

---
- ansible.builtin.debug:
    msg: "{{ item }}"
  with_items:
    - foo

In this case, we’ve made it clear that “foo”` is not a variable, but rather a string value. By providing it in a list format, we remove the ambiguity.

2. If “foo” is indeed a variable:

---
- ansible.builtin.debug:
    msg: "{{ item }}"
  with_items: "{{ foo }}"

Here, we’ve used the full variable syntax by enclosing “foo” in double curly braces {{ foo }}. This unequivocally indicates that “foo” is a variable that should be interpreted as such.

Benefits of Clarifying Expressions

Clarifying expressions as either variables or strings offers several advantages:

1. Code Readability: Clear, unambiguous code is easier for both the original author and other team members to read and understand.
2. Maintainability: Explicit expressions reduce the risk of future misunderstandings, making it simpler to maintain and update the code.
3. Debugging: When issues arise, having clear expressions can expedite the debugging process and lead to faster issue resolution.
4. Team Collaboration: In a collaborative environment, using standard practices for expressing variables or strings enhances team communication.

Conclusion

Ansible Error 104, “Deprecated Bare Vars”, serves as a valuable reminder to maintain code clarity and consistency in Ansible playbooks. By providing explicit indications of whether an expression is a variable or a string, you can improve code readability, maintainability, and debugging. In the world of automation and orchestration, clean and understandable code is essential for achieving reliable and efficient results. So, when working with Ansible, remember to make your intentions clear and your code unambiguous.

Academy

Learn the Ansible automation technology with some real-life examples in my Udemy 300+ Lessons Video Course.

My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps

Donate

Want to keep this project going? Please donate

Patreon Buy me a Pizza