Variable naming
This is maybe the most important part of the naming convention.
Variable naming is important so that there will be no namespace conflicts with unexpected results as a side effect. When variable naming is not done correctly, the contents of a variable might not always be what you expect it to be, when it is overwritten by another task.
Think of the inventory variables in ansible as layers of a cake, but when the name is reused, they will overwrite eachother!
Variables that you define at runtime must be unique, or you might overwrite a value that is needed elsewhere and will give unexpected results.
you want distinct variables so it looks nice and they won't interfere with eachother.
This will make maintenance much easier as you know you won't have to look for a variable with the same name anywhere else. It will make code reuse
easier.
Implementing this needs to get some more thought, but it will save time in the end.
How do we create unique variables
As we breakup the code into pieces, we lose some oversight over variable names. Next a few rules to ensure variable names will be unique:
Naming convention
Variables should conform to the following naming convention
Role variables
Variables orgiginating and used in a role, should start with the role name prefix, if you use ansible-lint on a role, you will get an error is you don't.
So for the role:
role_do_something:
- name: set role_vars
ansible.builtin.set_fact:
role_do_something_varname1: "This is the first unique var"
This way the variable name is always unique, as long the role_name is unique in a play.
When you create roles for almost every action you do in a play, a play will just be a collection af roles to run.
other variables
If you need additional variables, refer below, where every variable gets a name with the structure mentioned, so we can see what is is used for and where it comes from.
<start>_<middle>_<name>
Where <start> should refer to the provenance of the variable like:
* inv for inventory
* ply for play
Where <middle> should refer to the product for which the variable is appropriate.
Where <name> should be a descriptive name for the variable.
Inventory variables
The very top layer is the inventory, here the variables are difined on the global
level, these variables are availlable for each play on a host, depending on the
grouping of these variables in your inventory.
The inventory variables should be well documented and never be overridden in a play,
if this should be needed anywhere, you should check your inventory for errors.
Temporary variables
Tempory variables that are created and used inside a play or a role, such as registered
values and loop variables should also be unique, within the role or play.
Registered values
A registered value should alway start with an underscore and must be unique for the play.
Because this is a variable that will not be used outside the playbook, there is no further requirement.
Loop variables
Loop variables should never be "item", but start them with loop_ followed by a descriptive name.
This ensures the uniqueness for the loop_var and will reduce namespace conflicts.