On lut 17, Demetri A. Mkobaranov wrote: In short: these separate 'main_env.yml' tasks set up "environment" for other roles to work with. If they are present in the playbook of a given role, you should include them in the custom playbooks as well. A bit longer explanation: DebOps is designed with a clear separation between roles in mind. Each role takes care of its own "service", and when you want to configure something for a different role, for example open a firewall port for the webserver, you need to pass the configuration via dependent variables on the playbook level. Even though roles in the same playbook can see their own variables, since they are in the same "namespace", they strictly do not access them directly - this permits us to mix and match roles in different playbooks without the risk of referencing a variable that's suddenly not defined. Some roles however are more dynamic. For example, the 'postfix' role wants to open ports in the firewall for the 'smtp', 'submission' and 'smtps' services, but only if these services are actually used. The decision when to use these services is done in a template ('templates/lookup/postfix__env_active_services.j2') based on the contents of the 'postfix__combined_mastercf' variable. Ordinarly, all variables in roles in the same playbook are accessible, so most of the time the 'ferm' role can read the variable defined in another role, usually named '<role>__ferm__dependent_rules' and configure the firewall accordingly. However in the 'postfix' case, the template that is looked up during the variable resolution is stored in the 'postfix' role, not the 'ferm' role. If we would pass the variable with 'lookup("template")' directly to the 'ferm' role, Ansible would try and look for the template in the 'ferm' role which is incorrect. The solution to this is to prepare an additional variable using the 'set_fact' Ansible module. We do that with the 'main_env' task list from the 'postfix' role which gets executed before the 'ferm' role. The variable stays resolved with the list of services that we want opened and can then be referenced in the 'postfix__ferm__dependent_rules' variable which is passed to the 'ferm' role. When we do the 'set_fact' task, Ansible is inside of the 'postfix' role and can find the correct template. Of course it could be a bit easier to rearrange the roles, have 'postfix' role be executed before the 'ferm' role and just set the relevant variable inside of the 'postfix' role itself... However the order of the roles in the playbook determines the execution order of the handlers which are used to restart services. I want to be sure that the firewall rules are set up before Postfix service is restarted, to be on the safe side. And, I want to keep the preferred order of the roles in DebOps playbooks somewhat consistent, with the "dependent roles" being applied before the main role of a given playbook. There are of course exceptions, but they are usually for a specific reason. Cheers, Maciej