# Avoid conflicting roles on same machine

**URL:** <https://forum.ansible.com/t/avoid-conflicting-roles-on-same-machine/21921>\
**Category:** Ansible Project\
**Created:** [July 5, 2016, 11:54am UTC](https://forum.ansible.com/t/avoid-conflicting-roles-on-same-machine/21921 "2016-07-05T11:54:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kai\_Stian\_Olstad](https://avatars.discourse-cdn.com/v4/letter/k/e19adc/32.png) [@Kai\_Stian\_Olstad](https://forum.ansible.com/u/Kai_Stian_Olstad)\
**Post date:** [July 5, 2016, 11:54am UTC](https://forum.ansible.com/t/avoid-conflicting-roles-on-same-machine/21921/1 "2016-07-05T11:54:16Z")

</div>

Hi

I have 4 roles, nginx, apache, kibana and grafana.

The kibana role has a requirement to the nginx role and grafana role has a requirement of the apache role.  
Since both nginx and apache uses the same port numbers 80 and 443, they are in conflict with each other and can't run on the same host.  
This also means the kibana and grafana roles can't be on the same host.

Is there a way in Ansible to make sure it fails, ideally before any changes has been made, if they are included in the same playbook on the same host?

---

<div class="post-metadata">

**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\
**Post date:** [July 5, 2016, 8:25pm UTC](https://forum.ansible.com/t/avoid-conflicting-roles-on-same-machine/21921/2 "2016-07-05T20:25:42Z")

</div>

You could probably do something clever with setting vars and when: clauses,  
but I'm not sure how that will help you; you still won't have a  
working play right?

At the end of the day Ansible is a force multiplier for you to compose  
systems with.  
I've run kibana and grafana (the html5 versions, anyway) perfectly well on  
both apache and nginx, why not just change the roles?

---

<div class="post-metadata">

**Author:** ![Kai\_Stian\_Olstad](https://avatars.discourse-cdn.com/v4/letter/k/e19adc/32.png) [@Kai\_Stian\_Olstad](https://forum.ansible.com/u/Kai_Stian_Olstad)\
**Post date:** [July 6, 2016, 7:18am UTC](https://forum.ansible.com/t/avoid-conflicting-roles-on-same-machine/21921/3 "2016-07-06T07:18:19Z")

</div>

> You could probably do something clever with setting vars and when: clauses,  
> but I'm not sure how that will help you; you still won't have a  
> working play right?

I would like the play to fail, so the user get a message that the roles is in conflict with each other.  
So I could set a fact in a apache role and check if it exist in nginx and vice versa, and fail if it's defined.  
It will at least give the user a message, but not before some changes has been done on the host.

> At the end of the day Ansible is a force multiplier for you to compose  
> systems with.  
> I've run kibana and grafana (the html5 versions, anyway) perfectly well on  
> both apache and nginx, why not just change the roles?

I need some auditing for searches made with Kibana and Kibana uses POST.  
Reliable and good POST logging with Apache is not easy but very easy to do in Nginx.

All other roles uses Apache, reason for this is that Kerberos, Singel Sign On and LDAP is very easy to implement in Apache, not so easy in Nginx.

---

<div class="post-metadata">

**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\
**Post date:** [July 7, 2016, 7:32pm UTC](https://forum.ansible.com/t/avoid-conflicting-roles-on-same-machine/21921/4 "2016-07-07T19:32:52Z")

</div>

Fair enough - I'll be honest, I thought you might have been  
overthinking your problem  
but I can see how a safety net might help you. especially if you're  
writing roles for others  
to use.

In that case I'd do something lightweight, like setting  
a 'no\_nginx' var/fact in the apache role, which your nginx role checks for  
and causes it to skip/fail with an error. It's not \_too\_ ugly and it's  
isolated to  
the role.

I've done ugly conditionals in our main playbook before now using conditional  
roles/includes

( see [http://docs.ansible.com/ansible/playbooks\_conditionals.html#applying-when-to-roles-and-includes](http://docs.ansible.com/ansible/playbooks_conditionals.html#applying-when-to-roles-and-includes)  
)

- we usually used this in cases where we were replacing some components across  
&nbsp;&nbsp;several environments over a course of weeks, but still wanted to use  
a single site.yml  
&nbsp;&nbsp;to manage the environments. Rather than adding conditional logic to  
all our old roles we wrote new  
&nbsp;&nbsp;ones and set vars in each environments inventory to selectively  
enable roles in the play.  
&nbsp;&nbsp;Once it was on live, we just replaced the old role with the new one  
and took out all the conditional logic.

Like I said, not my proudest coding achievement but it was gone in the  
next commit 🙂
