How Exactly Does Ansible Parse Boolean Variables?

dokaspar picture dokaspar · Dec 18, 2017 · Viewed 23.5k times · Source

In Ansible, there are several places where variables can be defined: in the inventory, in a playbook, in variable files, etc. Can anyone explain the following observations that I have made?

  1. When defining a Boolean variable in an inventory, it MUST be capitalized (i.e., True/False), otherwise (i.e., true/false) it will not be interpreted as a Boolean but as a String.
  2. In any of the YAML formatted files (playbooks, roles, etc.) both True/False and true/false are interpreted as Booleans.

For example, I defined two variables in an inventory:

abc=false
xyz=False

And when debugging the type of these variables inside a role...

- debug:
    msg: "abc={{ abc | type_debug }}  xyz={{ xyz | type_debug }}"

... then abc becomes unicode but xyz is interpreted as a bool:

ok: [localhost] => {
    "msg": "abc=unicode  xyz=bool"
}

However, when defining the same variables in a playbook, like this:

  vars:
    abc: false
    xyz: False

... then both variables are recognized as bool.

I had to realize this the hard way after executing a playbook on production, running something that should not have run because of a variable set to 'false' instead of 'False' in an inventory. Thus, I'd really like to find a clear answer about how Ansible understands Booleans and how it depends on where/how the variable is defined. Should I simply always use capitalized True/False to be on the safe side? Is it valid to say that booleans in YAML files (with format key: value) are case-insensitive, while in properties files (with format key=value) they are case-sensitive? Any deeper insights would be highly appreciated.

Answer

techraf picture techraf · Dec 18, 2017

Variables defined in YAML files (playbooks, vars_files, YAML-format inventories)


YAML principles

Playbooks, vars_files, and inventory files written in YAML are processed by a YAML parser first. It allows several aliases for values which will be stored as Boolean type: yes/no, true/false, on/off, defined in several cases: true/True/TRUE (thus they are not truly case-insensitive).

YAML definition specifies possible values as:

y|Y|yes|Yes|YES|n|N|no|No|NO
|true|True|TRUE|false|False|FALSE
|on|On|ON|off|Off|OFF

Ansible docs confirm that:

You can also specify a boolean value (true/false) in several forms:

create_key: yes
needs_agent: no
knows_oop: True
likes_emacs: TRUE
uses_cvs: false


Variables defined in INI-format inventory files


Python principles

When Ansible reads an INI-format inventory, it processes the variables using Python built-in types:

Values passed in using the key=value syntax are interpreted as Python literal structure (strings, numbers, tuples, lists, dicts, booleans, None), alternatively as string. For example var=FALSE would create a string equal to FALSE.

If the value specified matches string True or False (starting with a capital letter) the type is set to Boolean, otherwise it is treated as string (unless it matches another type).



Variables defined through --extra_vars CLI parameter


All strings

All variables passed as extra-vars in CLI are of string type.