Ansible troubleshooting - Error 104: Deprecated Bare Vars

How to Solve the Ansible Error 104: Deprecated Bare Vars

October 31, 2023

Access the Complete Video Course and Learn Quick Ansible by 200+ Practical Lessons

#ansible-error #ansible-best-practices #ansible-playbook #ansible-troubleshooting #automation #infrastructure-as-code #ansible-linting #ansible-coding #devops #it-automation

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 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'.

The Best Resources For Ansible

Certifications

The Linux Foundation Linux Performance Tuning - Build a broad toolkit to optimize Linux performance from the kernel up

Coursera Pro - Unlimited access to 7,000+ world-class courses, hands-on projects, and job-ready certificate programs—all included in your subscription

Video Course

Udemy: Learn Ansible Automation in 250+examples & practical lessons: Learn Ansible with some real-life examples of how to use the most common modules and Ansible Playbook

Printed Book

eBooks

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:

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.

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:

Code Readability: Clear, unambiguous code is easier for both the original author and other team members to read and understand.
Maintainability: Explicit expressions reduce the risk of future misunderstandings, making it simpler to maintain and update the code.
Debugging: When issues arise, having clear expressions can expedite the debugging process and lead to faster issue resolution.
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.

Subscribe to the YouTube channel, Medium, and Website, X (formerly Twitter) to not miss the next episode of the Ansible Pilot.