Switch ansible from playbook to roles

[willoucom]

I am in love with this project, and i'm also in love with Ansible.

At the current stage of the project, I think that having most of the logic in playbooks will lead to future problems, such as disaster recovery or update difficultie

I also think the current system with shell scripts and dialog is an excellent solution that offers great possibilities and should be future-proof.

I have a lot of experience with Ansible, so it's possible that these changes seem simple to me while it may not be so clear to you, and I apologize for that. Please note that I am offering my help in making these changes, I am also willing to make them if you are comfortable with the demonstration.

About the changes I want to propose.

At first, create a single playbook and move current logic in different roles.
The syntax is roughly the same between playbook and roles.
In this playbook, we add tags on each entry, one for each role.
Then, update the shell scripts to call tag instead of different playbook.yml (doc: https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html)

For example, if we move install_cockpit.yml inside a role with the tag "cockpit" in the main playbook.yml, we can call this role with the command : ansible-playbook -t cockpit playbook.yml and this is where the magic start to shine, we can call multiple tags in one command, ansible-playbook -t cockpit,samba playbook.yml

Next step of the magic, we can also use host variables to further simplify the operation (doc: https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#adding-variables-to-inventory).

For example, we set in the playbook the "cockpit" role is attached to the variable "cockpit", then in the inventory, we add the variable "cockpit" to the host localhost.
The variable file is a plain ini file or a yaml file, and since the file will be saved on disk, the user's configuration will persist.
Then we only have to run ansible-playbook playbook.yml to apply the exact same configuration each time, permitting the user to update his installation with a simple and unique command.

The conversion from playbook to role can be done one playbook at a time and with minor modifications each time.
There is many other things we can do with Ansible, but I suggest to keep it simple.

Thank you so much for your time, I look forward to discussing this topic with each of you.

[sairuk]

This discussion is a continuation of retronas/retronas#25

[willoucom]

I created a little demonstration in retronas/retronas#44

To test:

• checkout the branch
• run the command ansible-playbook playbook.yml in the ansible folder

More tests:

• run the command ansible-playbook playbook.yml -t romdir to only run the romdir role (you can also test with the tag dependencies)

Notes:

• If you run the command multiple times, ansible will only check for changes (try to delete a directory in the roms folder)
• I have added the user's creation in the dependancies role because the user is required for the chmod

[sairuk]

Personally I really like this,

I think a bash code refactor could really benefit. Dialogs could become checklists that build a list of tags to deploy etc.

Some questions,

• what are the caveats with on-boarding devs that might be familiar with basic yaml/ansible but have not touched roles?
• does the .yamllint file need to be per role or can we have it as a global thing?
• I assume we could hook up the molecule tests as github actions right?
• is galaxy_info a requirement of a role or is it something that just fronts the Ansible catalog metadata?

From memory we can still define roles into playbooks and bring them in to run a single playbook if we choose too.

I've done some hardcore nested ansible stuff for infra deploys but it was all playbooks/tasks I didn't dig into roles, nested ansible can be a pain because you sacrifice the ability to start at a targeted tasks.

It is good but I guess everything just needs a little more thought before it hits a role.

[sairuk]

I am planning changes to they way items are launched so they are uniform across the TUI/WUI using keywords instead of commands and offloaded to an ansible_runner script, this is an intermediate step with the intent that when we get back to looking at roles the keyword approach should be interchangeable with tags.

So the theory goes, lets see if it plays out.