Tool showing all variables and their effective value for playbooks/roles

Get Help
1

hi everybody,

to me managing variables is one of the main challenges in Ansible and I have quite often re-arranged this when developing a role or playbook.

What I would love to have is a a tool, let’s cal it variable-lint, that is able to find all variables in every corner of a playbook/role …

  • display the variable name
  • display it’s value (or the fact it is not defined)
  • display where that value is defined (all instances, sorted by precedence)
$ variable-lint myplaybook.yml
{{ var1 }}:value1:file_called.line-no:file_defined.line-no   # instance with highest precedence
{{ var1 }}:value1:file_called.line-no:file_defined.line-no   # instance with second highest precedence

does anything like that exist? It’s not ansible-lint

2

What are you trying to achieve / accomplish by doing this? Once that’s known it should point in a clearer direction to solve your issue and let others know scope.

3
  • it provides clarity while developing a playbook/role and likeweise smoothing out the dev process.
  • it also gives a hint at which places to add values for different runs (i.e. same thing, but different environments) or which values need to be provided on execution (--extra-vars)
4

This is still an endstate not a goal, so doesnt inform of scope.

for clarity, example

  • i want to ensure all variables are present
  • i want to see what variables are used
  • reduce errors due to… (forgetting to add to play, group vars etc, adding to defaults

essentially, it points to the issue/problem you have, not a endstate.

5

thx @jon-nfc … my mediocre command of the English language might play some part in this, but I have trouble understanding what you mean exactly.

difference of endstate vs goal vs scope is not really clear. But I guess we must not discuss semantics too much and try to be practical.

essentially, it points to the issue/problem you have, not a endstate.

the problem I am facing over and over again is that I am, especially when developing a little more complex things, I have trouble organizing variables and not only once I lost a bit of track where exactly which variable is been filled with content, and where it is called.

That can be due to the less then perfect skills I own and might not apply to more experienced users. But I guess there are other not yet perfect Ansible users/devs to whom such a tool might be helpful (at least for a certain period on the path to perfection).

6

Dont be concerned with language barriers, it’s enough to mention it for us native speakers to be more verbose when assisting.

I’m reasonably certain that everyone whom uses ansible has had the exact problem you’ve described. So I’ll provide what I did to remove the “problem” in this case I’ll call human error.

in your collection and roles dir, depending on what your working on. Take advantage of the default variables by simply creating a yaml in that dir and for every variable that you add to your playbooks/roles Always add it to the default vars. Additionally whilst creating your playbooks and roles, ensure that you can run it with only the default vars and no vars from inventory. That ensures that if you try to do a test run and it fails claiming a missed var, you know for certain you forgot to add the var to the defaults. In the defaults file is the location I document my vars and always ensure they are ordered alphabetically.

next step or concurrently, you can use the assert module. this module allows you to check if a var exists as an example (yes, you can do many different checks). I personally like to use the assert module for var checking at the top of any task or playbook im working on. Additionally, if you have any vars you dont want a default on, I personally still add it to the defaults file, although commented out. during testing the role/playbook define non-existant default vars via cli.

variable naming is always prefixed with role name, then task name then var name. For instance, if I had a kubernetes role the version variable would be called kubernetes_install_version. The install is the task file it was first used in.

With the above, 99% of your described issue should disappear.

7

There is ansible LSP (language server protocol) and it should support what you are looking for. This is called find references (Specification) and its “reverse” operations go to implementation (Specification) and go to definition (Specification).

Nothing of this is supported by ansible LSP unfortunately, but it is possible from my point of view with not many changes. I’ve also been missing this functionality of ansible LSP.

At the moment my workaround is simply using search funtionality in the project ( GitHub - dmtrKovalenko/fff: The fastest and the most accurate file search toolkit for AI agents, Neovim, Rust, C, Python, Bun and NodeJS · GitHub , might help here). All the variable names have role as prefix, so they are unique and easily searchable.

@oranod @gundalow FYI. I think this is very important addition to ansible LSP.

8

Ok easy done.

A lot of people when they ask for help, and the worst offenders are those who already have a better understanding of the issue. When they ask for help, they provide part or in some cases a solution to their own question (this is an endstate). Best case and even Im guilty of this hen asking for help is always explain the “why” to what you want and do include reasons.

A goal is what you want to achieve

and scope is defined restrictions or constraints or an area of the subject in question. in the context i used it, knowing your goal would allow me to know what area I needed to consider so as to assist.

9

Hi @dulhaver . I just want to point a few (of probably many) things that make implementing such a tool as variable-lint very hard or outright meaningless or impossible.

  1. Some variables in Ansible are tied to a host or a group and only --extra-vars can be considered really “global”. That being said, passing a playbook file as the only input for the imaginary variable-lint tool would not be enough information for it to resolve all the values of all of the variables. Some variables could also be only defined for certain hosts and not for the others. variable-lint would thus have to additionally take a host or a group (or a host pattern) as an input to resolve the variables… per host. This can already be done to some extend by the ansible-inventory tool. The downside is that it does not resolve jinja templating and it does not resolve role defaults… because…
  2. Some variables can be active (defined, have value and be actively used) if and only if some part of the code was executed (e.g. a role or a task with when condition). That means that to resolve some variables, a playbook has to be fully executed. This makes variable-lint meaningless.

A general advice for how to cope with “variable spaghetti” is to limit the number of places/scopes where variables are defined or assigned a value. For example, you could reduce this to:

  • role defaults (as a must)
  • host_vars and group_vars (counting this as one for the sake of simplicity)
  • extra vars

A simple recursive grep or a search in your IDE will in this case discover the vars quickly. If you are using set_fact and import_vars all over the place then, yeah, you are in for a lot of pain.

10

thks @bvitnik, fair considerations I guess. However complex is not the same a impossible.

I get from this discussion thus far … such a thing does not exist (even though there are workaround) and making one might not be trivial.

thanks anybody thus for for your input.