Ansible request for *Unix* playbooks - a playbook by name rather than named via role_name.

[aixtools]

Please put the name of the software product (and affected platforms if relevant) in the title of this issue

• Missing install
• Bug in ansible playbook
• Request for new playbook addition
• Reorganization

Details:
I've been working on reorganizing the AIX playbooks - and I am going to start looking at the organization of the other Unix playbooks.
Before getting started - I just want to verify that there is some agreement that that a playbook named, e.g., roles/something_todo/tasks/main.yml could also be named something_todo.yml - If the aforementioned main.yml is the only file in the role.

• Why I ask? Because - mostly - that is the current organization - the two roles Common and Nagios_Plugins are the exceptions:

aixtools@x064:[roles]find . -name \*.yml ! -name main.yml
./Common/tasks/Alpine.yml
./Common/tasks/CentOS.yml
./Common/tasks/Debian.yml
./Common/tasks/FreeBSD.yml
./Common/tasks/MacOSX.yml
./Common/tasks/RedHat.yml
./Common/tasks/SLES.yml
./Common/tasks/Solaris.yml
./Common/tasks/Ubuntu.yml
./Common/tasks/build_packages_and_tools.yml
./Common/tasks/openSUSE.yml
./Common/vars/Alpine.yml
./Common/vars/CentOS.yml
./Common/vars/Debian.yml
./Common/vars/FreeBSD.yml
./Common/vars/MacOSX.yml
./Common/vars/RedHat.yml
./Common/vars/SLES.yml
./Common/vars/Solaris.yml
./Common/vars/Ubuntu.yml
./Common/vars/openSUSE.yml
./Nagios_Plugins/tasks/nagios_CentOS.yml
./Nagios_Plugins/tasks/nagios_Debian.yml
./Nagios_Plugins/tasks/nagios_FreeBSD.yml
./Nagios_Plugins/tasks/nagios_MacOSX.yml
./Nagios_Plugins/tasks/nagios_RedHat.yml
./Nagios_Plugins/tasks/nagios_SLES.yml
./Nagios_Plugins/tasks/nagios_Solaris.yml
./Nagios_Plugins/tasks/nagios_Ubuntu.yml

• Above was all .yml files that were not named main - here are the main.yml files:

aixtools@x064:[roles]find . -name main.yml
./Ant-Contrib/tasks/main.yml
./CentOS6-Cent7SSL/tasks/main.yml
./Clean_Up/tasks/main.yml
./Common/tasks/main.yml
./Crontab/tasks/main.yml
./Debug/tasks/main.yml
./Docker/tasks/main.yml
./DockerStatic/tasks/main.yml
./GIT_Source/tasks/main.yml
./Get_Vendor_Files/tasks/main.yml
./IPv6/tasks/main.yml
./Jenkins_User/tasks/main.yml
./Kerberos/tasks/main.yml
./NTP_TIME/tasks/main.yml
./NVidia_Cuda_Toolkit/tasks/main.yml
./Nagios_Master_Config/tasks/main.yml
./Nagios_Plugins/tasks/main.yml
./Nagios_Tunnel/tasks/main.yml
./OpenSSL/tasks/main.yml
./Providers/tasks/main.yml
./Python2.7/tasks/main.yml
./Python3_Source/tasks/main.yml
./Security/tasks/main.yml
./Superuser/tasks/main.yml
./Swap_File/tasks/main.yml
./Tomcat/tasks/main.yml
./Vendor/tasks/main.yml
./Version/tasks/main.yml
./Xcode/tasks/main.yml
./adopt_etc/tasks/main.yml
./adoptopenjdk_install/tasks/main.yml
./ant/tasks/main.yml
./autoconf/tasks/main.yml
./ccache/tasks/main.yml
./cmake/tasks/main.yml
./curl/tasks/main.yml
./disable_gui/tasks/main.yml
./freemarker/tasks/main.yml
./gcc_10/tasks/main.yml
./gcc_48/tasks/main.yml
./gcc_7/tasks/main.yml
./gcc_9/tasks/main.yml
./git-hg/tasks/main.yml
./gmake/tasks/main.yml
./jckservices_iptables/tasks/main.yml
./linux_installer/tasks/main.yml
./local_srcinstall/tasks/main.yml
./macos_codesign/tasks/main.yml
./maven/tasks/main.yml
./nasm/tasks/main.yml
./riscv_cross_compiler/tasks/main.yml
./vsftpd/tasks/main.yml
./zulu7/tasks/main.yml

• In my book - that is a feeble attempt to use roles. In fact it is simply using the ansible module role: rather than include_tasks:
• But, that is just my humble opinion. What is yours?

[aixtools]

• update: Looking at the role Common - I see nothing that I expected. This is a role I would call platform or something compareable - as the main task is:

##############################
# OS setup and configuration #
##############################
# If this errors, upgrade ansible to >=2.4
- name: Perform OS setup and configuration
  include_tasks: "{{ ansible_distribution }}.yml"
  tags: main

[sxa]

The Common role (whether platform is a better name or not doesn't really matter) is mostly for installing a base set of packages from the package manager. It's split into the different distributions because there are so many variants. As you've seen from your last comment the main.yml calls the distribution-specific things. I suspect the reasoning behind the Nagios role is similar. @Willsparker any further input?

I'm not saying that's the best option - just explaining how it's currently done and that was put in place a long time ago :-)

[Willsparker]

Yep, so the way the Common role is how I would personally setup a multi-platform role that has some tasks for some platforms and not for others. main.yml is the correct thing to call the 'first' task file, as Ansible will look for and run main.yml, when including a role; from main you'd then call the specific platform files - this is similar to how Python scripts are written where main is a sort of 'top-layer' that just calls other functions.

This is how I would also setup roles that have multiple functions, but you may not want to necessarily call all of them; (I am aware that I wrote this so I am biased but...), something like this:
https://github.com/Willsparker/AnsibleBoilerPlates/tree/main/Nagios/playbooks/roles/Nagios_Host/tasks

I do concede, this has a downside where handlers can't be used when using include_tasks:.

I would like to keep the original roles, as roles, as it is keeps them separate . As well, even if roles are simple and are literally just a task file, if they're expanded in the future to use more role functionality (such as templates, default variables and variable files), we'd have to convert the playbooks back to a role-based process. Personally I think with the rewrite ( #2492 ) , we'll likely see roles use a lot more of this functionality anyway.

[aixtools]

• as to leaving the tasks named as roles - if that is what you want, so be it. I wont bother thinking about it.
• reminder: my viewpoint, for now, is fresh eyes. I mention what surprises/confuses me. Over time I too become part of the establishment aka biased.
• my bias would be, e.g., to take something like the MANY gcc (so-called) roles and integrate them into a gcc role.
• part of integration is to also document why one platform details differs from another - rather than expect a reader to be clairvoyant. I seriously miss documentation. (As an AIX expert I see things I feel are not needed, potentially dangerous for portability on AIX, yet dare not make (or discuss) changes - as I have no reference.
• in short, documentation is weak at best.

many thanks for responses!