Harmonize handling of per-distro role variables

[emontmas]

Current status

SEAPATH flavors have minor differences in file paths, command names, packages name, ... depending on the underlying distro.
These differences are currently handled in different ways by roles and playbooks:

• Some roles rely on variables given by the calling context (playbook), some roles have per-distro variable files they load dynamically depending on the host SEAPATH distro.
• Prerequisites playbooks are separated by distro, allowing to configure role varibales per-distro in the playbook.
• Other playbooks, such as hardening playbooks, are common and will rely on the roles integrated per-distro var files, or on global vars files.

This management of roles variables is not ideal.
By design, roles are supposed to be easily reusable. Having per-distro variables files embedded in roles instead of relying on role variables reduce the reusability and can be hard to maintain with a growing list of SEAPATH flavors.

Detailed Description

Rely on role variables as customisable input

Some roles like configure_seapath_distro, used for exemple in the seapath_setup_prerequisdebian.yaml playbook, already rely on role variables.
That way, the role is like a "function" and takes input parameters from the calling context to do its tasks.
This role variables as input aspect could be generalised to improve code maintainability and integration of future SEAPATH distros.

Move per-distro role variables in per-distro var files at repo level

This means also removing the per-distro files in roles, like in the snmp role.

Distro-specific role variables for all roles could be gathered in single distro-specific file at the root of the repo, in vars/. This file can then be dynamically included by the common playbooks such as the sepath_setup_*.yaml playbooks depending on the seapath_distro var.

E.g.:

# var/Debian.yaml

cukinia_command_path: "cukinia"

configure_hardening_ssh_service: ssh
configure_hardening_etc_securetty_group: sys

# [...]

cephadm_install_cephadm_uid: 1001
cephadm_install_cephadm_gid: 1001

# [...]

These variables are purely dependant on the underlying distro and won't be configured by the user.
Gathering all role variables for a given distro in a single file also improves maintainability, as distro-specific customisation won't be scattered anymore.
Moreover, adding a new SEAPATH distro means adding a single new file, with the correct customisations.

Note that the alternative would be to get rid of any distro var files, duplicate any playbook for every available SEAPATH flavor, and specify the distro-specific variables in theses playbooks. However, this would duplicate a lot of code and so many similar playbooks would impact readability of the repository.

Create per-distro hardening playbooks

Hardening tasks are a bit different from other configuration tasks. They don't apply to all distribution (e.g. SEAPATH Yocto don't use hardening playbooks).
For that reason, it may be considered to create per-distro hardening playbooks, just like the prerequisites playbooks.
In that case, of course, distro-specific role variables could be specify in the playbooks.

Benefits to SEAPATH

• Improved maintainability of the distro-specific variables.
  • One SEAPATH distro == one variable file
  • Easiest integration of new SEAPATH distro.
• Roles are truly reusable.
  • Distinction between task (function) and task customisation / input (function call).

Work to be done

• Remove distro-specific var files from roles and set their content in a common distro file at the root of the repo in vars/.
• In common playbooks, dynamically load the var file corresponding to seapath_distro.
• Separate hardening playbooks in distro-specific hardening playbooks, like prerequisites playbooks. This means per-distro hardening is more flexible.

What are your thoughts @eroussy @dupremathieu @insatomcat?