Every machine or machine group has a specific configuration. For the creation and the management of a flexible and versatile environment, it is necessary to have a flexible and versatile configuration. The usage of variables enables this goal without the (re-)development of a code. This section gives an overview about the use of variables of the SDM framework.

Variable types and names

Ansible provides like Python dynamic variables. Furthermore, it is possible to give a variable an (nearly) arbitary name. An overview of the rules for creating variable names can be found in the Ansible documentation [1]. But the usage of arbitary names within an infrastructure is not the best way and fails when multiple code snippets use the same variable name for different purposes. As a result, the SDM framework distinguishes variables in three different ways:

All types have in common, that Ansible does not validate these provisions. So the end user and the developer of a role have to respect this.

Definition places

There are many ways to define variables. In order to guarantee flexiblity and versatility end users are only allowed to use host and group variables. They are defined in files inside the directories host_vars for host specific and group_vars for group specific variables. It is also possible for end users to define variables in customized files with the set command of the Jinja template engine. These files must be located in the directory files. Role developers are limited to the directories vars and defaults of each role, the Ansible module set_fact and the set command of the Jinja template engine.

Access mechanisms

As in section “Role” described the SDM framework follows two approaches to abstract an entire intrastructure (vertical hierarchy) on the one hand and to refine existing roles (horizontal hierarchy) [2]. Both have explicit specifications for accessing variables. Variable access in vertical means that a role uses a variable for its procedures. It does not mean that superordinated roles can not set variables for a special role before this is executed. But it is neither allowed to use these variables in their own procedures.

The vertical hierarchy allows the following access rules:

The following figure shows the access mechanisms in vertical direction:

vertical hierarchy (varaible access)

Access mechanisms for variables between roles in vertical direction

In the horizontal direction a role can use its own and the variables of all parent roles along the role chain. The reverse direction is not allowed. The following figure shows the access mechanisms in horizontal direction:

horizontal hierarchy (variable access)

Access mechanisms for variables between a role and its derived roles