# Role conflicts **URL:** \ **Category:** Ansible Project\ **Created:** [August 31, 2013, 3:48am UTC](https://forum.ansible.com/t/role-conflicts/13397 "2013-08-31T03:48:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![kahlil.hodgson](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@kahlil.hodgson](https://forum.ansible.com/u/kahlil.hodgson)\ **Post date:** [August 31, 2013, 3:48am UTC](https://forum.ansible.com/t/role-conflicts/13397/1 "2013-08-31T03:48:13Z")
Awesome work on the role dependencies stuff! I'll be using that a lot. It occurs that it might also be good if we could specify that two roles conflict with each other. A concrete example: I have a 'shorewall' role that I use for setting up and configuring shorewall on all my servers. This has become too complex because of one special case with complex requirements: the gateway routers. So I factor that case out into a separate 'shorewall-gateway' role. Because these have been spilt up, I can greatly simplify the organisation and conditional logic in both roles. However, I now have to be very careful that I do not apply both roles to the same server. I would be great if I could put, say: conflicts:     - { role: shorewall } in the meta/main.yml for shorewall-gateway so that a fatal error is generated if I ever try to combine the two roles. Thoughts? K Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281 Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925 ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [August 31, 2013, 1:46pm UTC](https://forum.ansible.com/t/role-conflicts/13397/2 "2013-08-31T13:46:01Z")
Something we can consider if we find it coming up a lot. Until then, let’s get this out there and gather feedback as it’s used over time. We haven’t needed “task conflicts” pre-roles before, or even this before we what role-deps, so I’m suspecting it doesn’t come up too frequently. I also imagine conflicts probably don’t work so well when sharing roles with others, as how could you know all the possible things they would conflict with, etc, so this would be more of a feature for your particular environment? My initial advice is only apply one role or the other but not both 🙂 –Michael ---
**Author:** ![kahlil.hodgson](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@kahlil.hodgson](https://forum.ansible.com/u/kahlil.hodgson)\ **Post date:** [September 1, 2013, 5:45am UTC](https://forum.ansible.com/t/role-conflicts/13397/3 "2013-09-01T05:45:31Z")
> Something we can consider if we find it coming up a lot. Until then, let's > get this out there and gather feedback as it's used over time. True. I'm just throwing the idea out there to see if anyone else thought it might me useful. Definitely for exploration post 1.3 release. > We haven't > needed "task conflicts" pre-roles before, or even this before we what > role-deps, so I'm suspecting it doesn't come up too frequently. True, I only needed the concept because I was simplifying a complex role by splitting it into two disjoint roles. This gave me a much better model of my system. However, the fact that the two roles must never be to applied to the same host is now by convention rather that being explicit in the model. This is not so good. > I also imagine conflicts probably don't work so well when sharing roles with > others, as how could you know all the possible things they would conflict > with, etc, so this would be more of a feature for your particular > environment? I was actually thinking this would be great for sharing groups/pairs of roles for setups that have distinct types of hosts. Database replication with masters and slaves, virtualization with hosts and guests come first to mind. I thought it would be much easier to distribute a pair of roles (virt-host and virt-guest, say) which could be simplified (safety checks eliminated, etc) because you knew they could never be applied to the same host. I've not built roles for these cases yet, but it would love to know whether anyone else thinks the idea has any merit. > My initial advice is only apply one role or the other but not both 🙂 Yup, and if I make a mistake, I get to keep both parts 😉 The discussion around the diamond pattern suggest others are creating complex dependency relationships. Consider the following: 1. A depends on B 2. B depends on C 3. C depends on A' 4. A conflicts with A' Really easy for someone (say a new team member) to assert 1. without being aware of 4. I know I'm safe, because I wrote the roles. But if I go on leave ... Anyway, just throwing the idea out there 🙂 Enjoy the rest of your weekend! Cheers, Kal Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281 Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925