Access to inventory groups hierarchy

Archives Ansible Developer
1

Hi!

I would like to start a discussion about access to inventory groups hierarchy. I have already created an issue describing the problem.

Our use case is re-creating inventory groups hierarchy in Icinga`s configuration, so that we have 1:1 mapping betwean hostgroups and inventory groups. One way do achieve it would be to create a new variable “group_children” just like i.e. ‘groups’, but instead of a list of host - it would contain list of child groups or empty list if there are none.

So, assuming that we have inventory like this:

[market-za:children]
front-za
backend-za

[front-za]
front1
front2

[backend-za]
backend1
backend2

we would have:

group_children[‘market-za’] = [‘front-za’, ‘backend-za’]
group_children[‘front-za’] =

What do you think about that ?

Thanks in advance for a reply.
pr

2

​Sorry I didn't reply earlier, I hoped for other people having a use case
here too :)​

group_children['market-za'] = ['front-za', 'backend-za']
group_children['front-za'] =

​This sounds good to me. I'd add a var for parent groups to that, too, as
this is also available in the Group object.
Given hosts have a 'group_names' containing all groups (upwards
recursively​) it is a member of, it might also makes sense here to have a
var containing only the direct parents.

So:
- group_children has keys for every group
- group_parents has keys for every group
- group_names and group_names_parents would exist for every host, the
former alreqady exists.

Given this, a word on a related use case that is covered by the same
subject, and in which I have an interest.

I would like to be able to more easily target multiple sets of clusters
within the same playbook in a serialized way, e.g. applying the same role
to deploy different apps.
Given say 100 tomcat clusters, deployed with 1 set of roles in the same
way, but with different apps, parametrized via the inventory, I need to
deploy one node at a time.

Now, this is possible with serial: 1 of course, but when a deploy consists
of upgrading several related application, it would be a big benefit to be
able to deploy several clusters at the same time, but each node within a
given cluster 1 at a time.
So, functionally, that would be something like "serial: per node in
cluster".

Code wise, this would translate into runner using serial batches, where the
first batch contains 'all the first nodes in the cluster', the next batch
all second nodes, and so on.

I'm not sure ho wthis could be easily defined though. Given all nodes of a
paticular cluster are part of a particular application group, and those
application groups would be part of, say, a tomcat group,
parent/grandparent group membership could be looked at, but so far I
couldn't think of a decent way to model that.

Thoughts?

  Serge

3

[snip]

Code wise, this would translate into runner using serial batches, where the first batch contains ‘all the first nodes in the cluster’, the next batch all second nodes, and so on.

I’m not sure ho wthis could be easily defined though. Given all nodes of a paticular cluster are part of a particular application group, and those application groups would be part of, say, a tomcat group, parent/grandparent group membership could be looked at, but so far I couldn’t think of a decent way to model that.

Not sure if that what you meant, but you could say something like that:

  • hosts: tomcats
    serial: 1/(region-*)

i.e. give a pattern for the child groups under the tomcats group. Less magic involved.

4

Something like that yes​!

What do you mean exactly by "less magic involved"?

5

you were talking about looking at group relationships etc. It sounded like ansible should just figure out on its own how to partition your hosts to clusters, hence magic :slight_smile:

6

I’ve closed this ticket as I don’t think we need to clutter up the variable space with a lot of magic and objects about how this works.

If you wanted to create some private fact module that used the inventory API, technically, you could, but I fear this is too far down the rabbit hole, and would bloat up the various dictionaries we are passing around for template purposes.

I’d like to take a step back to understand your use case and suggest perhaps better ways of writing your playbooks and templates, or organizing your icinga configuration, that could make this easier.

7

​The vars things was more the request of the OP.​
​My use case whas about serializing per clusternode, as describe in a
previous post. Not sure what info I could add to that.​