Role conflicts

Archives Ansible Project
1

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

2

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 :slight_smile:

–Michael

3

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 :slight_smile:

Yup, and if I make a mistake, I get to keep both parts :wink:

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 :slight_smile:

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