ansible-modules dependency graph

[markgraf]

SUMMARY

With currently 54 different interdependent modules, it would be uselful to know in which specific order they should be used. E.g. domain will throw an error if any of its locations or organizations do not exist.

Other modules will have similar dependency issues.

ISSUE TYPE

It would be useful to have dependency graph of the modules, or something like a roleplaying-games skill-tree for the modules. Or simply an ordered list of all modules to loop over.

Do you see a way of generating this? This is likely a documentation-issue.

[markgraf]

I created a dependency-graph with graphviz, see attached dot-file. The graph may be incomplete and certainly needs retouching by a graphviz-expert.

In order to get a list without circular dependencies, I removed two dependecies:

• architecure depends on operatingsystem and vice-versa. In my graph operatingsystem depends on architecture, but not the other way.
• hostgroup depends on itself, I've removed that, too.

With the help of tsort.g I converted the graph into a topologically sorted list:

gvpr -f tsort.g foreman-ansible-dependencies.dot | tac | sed 's/^/- /'

I'm currently testing if this really works as expected.

foreman-ansible-dependencies.dot.txt

[mdellweg]

arch and os have a many-to-many association relationship so their order should not even matter and hostgroup has a parent relationship on itself

[markgraf]

But the order does matter: If you try to create an architecture with operatingsystems, you need to create the operatingsystems first, or else your ansible-run will fail. So I'm deliberatly dropping this in the ansible-role I'm currently writing.

This is probably not the best approach, but keeping track of os and arch on both ends is more trouble than it's worth. Personally I think the OS knows better what architectures it supports than the architecture knows about OSes, so I'll keep this on the OS-side. YMMV.

The graph above is not entirely correct as of now. So I added the dependencies back to see if it changes the sort-order. sdiff tells me it doesn't, so here's a better graph: dep2.dot.txt

foreman-ansible-dependency-graph.pdf

[mdellweg]

But the order does matter: If you try to create an architecture with operatingsystems, you need to create the operatingsystems first, or else your ansible-run will fail. So I'm deliberatly dropping this in the ansible-role I'm currently writing.

This is probably not the best approach, but keeping track of os and arch on both ends is more trouble than it's worth. Personally I think the OS knows better what architectures it supports than the architecture knows about OSes, so I'll keep this on the OS-side. YMMV.

That is a good idea for using the modules in combination.

On the other hand it highlights that there are a lot of arrows in your graph, that all look the same, but have very different semantics. I think we should think who would be reading that graph and make it more accessible. For example having taxonomies (org/loc) is quite common. Would it be possible to mark the corresponding entities to rely on them by a special feature of their ellipse? That would reduce the number of arrows by about half i guess. In its current form, i fear that this diagram raises more question than it answers.

[markgraf]

Would it be possible to mark the corresponding entities to rely on them by a special feature of their ellipse? That would reduce the number of arrows by about half i guess. In its current form, i fear that this diagram raises more question than it answers.

Good question. This is about the second time I'm using graphviz, though, so I can't tell how.

Running the modules in the order given by gvpr -f tsort.g foreman-ansible-dependencies.dot | tac does seem to do what I need. At least the graph serves for that, even if it isn't easy on the eye :-)

Maybe close the issue and I open a new one, when I have a better graph?

[mdellweg]

Triage says, this is awesome, but understanding that graph is more like understanding foreman than understanding how to use the modules here. So we would love to see something like this in the documentation for foreman itself. Bonuspoints: Have another graph for katello.

[markgraf]

Let me finish my dockerized foreman at work first, I hope I have a better understanding of things after that. I've found no way of getting Katello into docker so far, but I guess I'll need a graph when/if I do, for the same purpose as above. I'll follow up with another issue then. That's probably better then keeping this one waiting.

[myllynen]

This would indeed by very helpful and providing even a basic list of the recommended configuration order would be a good starting point, a full playbook to include as part of the collection might be a separate consideration.

Here's a simple-but-helpful example for Ansible Automation Platform, just like with Satellite, it has many modules and configurations and some of them need to be created others so the order matters and even this kind of README and role is helpful for users:

https://github.com/redhat-cop/controller_configuration/tree/devel/roles/dispatch

Thanks.