# :children group syntax

**URL:** <https://forum.ansible.com/t/children-group-syntax/18711>\
**Category:** Ansible Project\
**Created:** [July 8, 2015, 2:53am UTC](https://forum.ansible.com/t/children-group-syntax/18711 "2015-07-08T02:53:02Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dan\_Mick](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@Dan\_Mick](https://forum.ansible.com/u/Dan_Mick)\
**Post date:** [July 8, 2015, 2:53am UTC](https://forum.ansible.com/t/children-group-syntax/18711/1 "2015-07-08T02:53:02Z")

</div>

Why does :children exist? Why couldn’t it be the case that groups of groups just recurse on their components, expanding as they go?

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [July 8, 2015, 1:07pm UTC](https://forum.ansible.com/t/children-group-syntax/18711/2 "2015-07-08T13:07:38Z")

</div>

its a way to distinguish between groups and hosts, as both entries can  
look the same.

---

<div class="post-metadata">

**Author:** ![Dan\_Mick](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@Dan\_Mick](https://forum.ansible.com/u/Dan_Mick)\
**Post date:** [July 8, 2015, 5:26pm UTC](https://forum.ansible.com/t/children-group-syntax/18711/3 "2015-07-08T17:26:28Z")

</div>

Well of course, but why? Why is it necessary to distinguish? “If group, expand group; if not, don’t”

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [July 8, 2015, 5:33pm UTC](https://forum.ansible.com/t/children-group-syntax/18711/4 "2015-07-08T17:33:00Z")

</div>

yes, how do you know if it is a group? it might be defined below, or  
it might be a host.

---

<div class="post-metadata">

**Author:** ![Dan\_Mick](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@Dan\_Mick](https://forum.ansible.com/u/Dan_Mick)\
**Post date:** [July 8, 2015, 6:03pm UTC](https://forum.ansible.com/t/children-group-syntax/18711/5 "2015-07-08T18:03:06Z")

</div>

you know if it’s a group if it has a name that matches a defined group name. Are you saying it’s solely to allow forward references to groups? If so, isn’t it an attribute of the child name itself that it refers to a group, and not “the supergroup can only contain children”?

i.e. any of these make more sense to me than the current definition:

1. expand if a name refers to a known group; otherwise don’t expand (doesn’t handle forwards)
2. make two passes through inventory files to handle forwards (might be tricky/undoable with dynamic inventory)
3. tag each groupname within the group:

[groupofgroups]  
host1  
group1:group

The way it is now, effectively defining every member of the group as a group with the unintuitive “children” on the enclosing group, seems the least intuitive of all, and unlike every other such tool.

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [July 8, 2015, 6:14pm UTC](https://forum.ansible.com/t/children-group-syntax/18711/6 "2015-07-08T18:14:42Z")

</div>

my initial proposal was require @ as the start of group names, many  
ways to do it, this is what the original author came up with and  
avoids multiple passes or non forward working groups.

Even better, you can create a inventory plugin that implements any  
format you want, but for now there are no plans to change the current  
format as its been the same for roughly 3yrs and most people are fine  
with it.

---

<div class="post-metadata">

**Author:** ![Dan\_Mick](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@Dan\_Mick](https://forum.ansible.com/u/Dan_Mick)\
**Post date:** [July 8, 2015, 6:41pm UTC](https://forum.ansible.com/t/children-group-syntax/18711/7 "2015-07-08T18:41:08Z")

</div>

Not suggesting change, just trying to understand rationale. I guess it’s the way it is because it’s the way it is.
