Revamp Repository According to Good Practices and Recent Ansible Versions

[andreashaerter]

The repository served us well but legacy Ansible version are going away in our target environments. So it is time for a thorough revamp to align with modern goof practices and recent Ansible versions. The following steps are necessary:

• Review Inputs:

  • Evaluate the current repository structure and practices against the Red Hat CoP Automation Good Practices Guide.
  • Identify deprecated features, outdated patterns, or other areas requiring modernization.

• Update to Recent Ansible Versions:

  • Ensure compatibility with recent Ansible releases.
  • Replace deprecated syntax or modules with their modern equivalents.

• Break down the findings into actionable issues.

Acceptance Criteria:

• A comprehensive review is conducted and documented.
• New issues are created to address the identified gaps, categorized for ease of implementation.
• The repository is ready for incremental updates based on the new issues.

[andreashaerter]

High prio:

• get rid of {{ role_name }}_initialized.
  Issues:
  • role_default: Remove {{ role_name }}_initialized #9
• 3.1.4. Naming parameters.
  Issues:
  • role_default: Prefixed internal variables by two underscores: __foo_variable #10
  • role_default: Prefix all tags within a role with the role name; Check tags in general #11
• 3.1.11. Platform specific variables.
  Issues:
  • role_default: Implement automatic search for plattform specific variables #12
  • role_default: Check for required facts, gather this subset if needed #13
• 3.1.19. Prefix task names in sub-tasks files of roles.
  Issues:
  • FIXME
• 3.1.20. Argument Validation.
  Issues:
  • role_default: give up assertation tasks for role argument validation? #1

Mid prio:

• 3.1.7. Package roles in an Ansible collection to simplify distribution and consumption
  Issues:
• FIXME

Further discussion:

• 3.1.12. Platform specific tasks:
  :
  • The subdirs like tasks/setup/ are clumsy for a template as they are not needed when there is only one default file. Any better include logic?
• 3.1.5. Providers and 3.1.13. Supporting multiple providers
  :
  • Prepare the template for provider_os_default? Use this pattern?

Do not implement:

• Variable for {{ role_name }}_extra_packages:
  • I don't like these because this can simply be achieved on playbook level / where the role gets called.