Hey guys,

I've been doing some work on how we might address providing Ansible roles that are tailored to the Turnkey Linux configuration of each appliance. I had suggested this a while back and Jeremy opened issue 553 on the tracker to document it. Here are the approaches that I've tried and my comments/suggestions along with requests for feedback.

The first approach that was in my original suggestion is to provide separate roles that would handle different custom configuration tasks in a similar manner to how I was using tklpatch to customize appliances. Some examples can be found at https://github.com/jstruebel/ansible-roles. The downside that I've found is that it doesn't fit well into the typical Ansible architecture. Because roles had to preserve existing settings in files the roles are kind of "hacky" in using line-in-file and shell commands. It was especially difficult, and most likely fragile with an existing config, for the Samba configurations. While I was working on that I came across the DebOps project which lead to my next two approaches.

The second approach was to find a way to leverage the DebOps roles yet customize the configurations to the default Turnkey Linux settings. My primary goal was to avoid customizing the roles directly so as to minimize the maintenance required, i.e. don't fork them. To that end I decided to create new playbooks that included a vars file that redefined the defaults for the DebOps variables so that they matched the default Turnkey config. Examples of this approach can be found in https://github.com/jstruebel/tkl-debops-plays. Some downsides to this approach are that it requires creating a playbook and vars file for every service that we want to support, it changes the operation of DebOps so that the user has to fork the site.yml in order to use other DebOps roles that haven't been included, redefining the variables creates problems for some conditionals in the roles, and it creates a entirely new set of variables in order to allow the user to customize the Turnkey defaults. The advantage to this approach is that no customizations to the roles are required and all of the Turnkey custom "stuff" can easily be provided in a single git repo for the user to clone. It also allows easily adding custom TurnKey roles, e.g. to configure TKLBAM.

The third approach grew out of the second approach, and this is to provide customized group_vars for each type of TurnKey appliance and a mapping of Turnkey appliance groups to DebOps roles. An example of this approach can be found at https://github.com/jstruebel/tkl-debops-inv. I feel that generally this approach is cleaner and more "Ansible". It also allows to minimize the maintenance since only the redefined defaults need to be included in the group_vars. Since it uses all of the DebOps playbooks, the user is free to mix in any other roles they may want by configuring their hosts into the appropriate group(s). Some downsides to this approach are that it mixes the Turnkey config with the user's own inventory, and it is harder to add custom Turnkey roles and have them executed along with the DebOps roles.

Right now, my preference would be the third approach since I think it fits better with how Ansible was designed to work. The downsides that I've come up with can be mitigated without much extra hassle for a competent user. For instance the inventory can be handled by the user keeping their site specific customizations in a branch. (it also has the advantage of pushing the user to keeping their inventory under configuration control) I haven't quite figured out how to address the custom Turnkey roles, the only ideas look a lot like the second and third approaches mixed which seems like it's adding complexity without much benefit. I welcome any comments and feedback on what I've done as well as suggestions for what approach would work best for Turnkey Linux (or possibly a new direction that I haven't thought of).