Hi,
I realise I'm very new to this project, so I put on my flame-proof
jacket before posting this ;-), but I *believe* the .ini style
inventory can be simplified and perhaps made a little more consistent.
It seems to me that the inventory is really just a graph of nodes,
where each node is basically a name and a set of variables. Doesn't
that mean that a host is really just a node with no children and a
group is a node with children?
Given that assumption, does it actually make sense to differentiate a
group of hosts:
[g1]
h1
h2
From a group of groups:
[g1:children]
g2
[g2]
h3
Couldn't this be simplified right down to:
[g1]
h1
h2
g2
[g2]
h3
This actually works quite nicely with vars too. For example if I have
lots of vars for a particular host, I would now have the option to use
a [:vars] block for a host as is currently possible for a group
instead of a long line of text:
[g1]
h1
[g1:vars]
a=1
[h1:vars]
b=2
c=3
...
z=26
I think the only downside to this is that you could accidentally end
up with something that was supposed to be a group but has no children,
and a node with no children is considered a host. However, I would
suggest that you didn't mean to have a group with no children, so it
should be removed (or commented out at the least).
If you're interested in this idea, and I won't be offended it you're
not, then I have a working .ini parser that builds the graph of nodes,
including support for vars, host ports, etc that I would be happy to
share or even try to wire in to Ansible myself.
- Matt
Hi,
I realise I'm very new to this project, so I put on my flame-proof
jacket before posting this ;-), but I *believe* the .ini style
inventory can be simplified and perhaps made a little more consistent.
It seems to me that the inventory is really just a graph of nodes,
where each node is basically a name and a set of variables. Doesn't
that mean that a host is really just a node with no children and a
group is a node with children?
[...]
If you're interested in this idea, and I won't be offended it you're
not, then I have a working .ini parser that builds the graph of nodes,
including support for vars, host ports, etc that I would be happy to
share or even try to wire in to Ansible myself.
Here you go, https://gist.github.com/2732574.
- Matt
Well, that would imply a host name and a group name couldn't be the same, right? It is very unlikely but it would be ambiguous in that case.
Otherwise I would agree.
-- Michael
Well, that would imply a host name and a group name couldn't be the same, right? It is very unlikely but it would be ambiguous in that case.
Yeah, that's true. I'm struggling to come up with a scenario where I
would ever name a host and group the same, but anything's possible.
Otherwise I would agree.
OK, have a sleep on it in case you think of anything else. If you want
me to have a play to see how it works out in practice then let me
know, or just grab the code and try it yourself.
Thanks for listening :).
- Matt
We're going to keep the 'children' syntax.
A few other reasons.
If you end up typo'ing a group name, you would end up creating a host, which would be confusing.
I am pretty sure I like things being explicit, and not mixing hosts and groups, since the file is easier to audit that way to see
if it is what you want it to be.
> Well, that would imply a host name and a group name couldn't be the same, right? It is very unlikely but it would be ambiguous in that case.
Yeah, that's true. I'm struggling to come up with a scenario where I
would ever name a host and group the same, but anything's possible.
We're going to keep the 'children' syntax.
A few other reasons.
If you end up typo'ing a group name, you would end up creating a host, which would be confusing.
Hmm, it's probably worth me mentioning that I have already
accidentally added a group to a non [:children] section and had the
exact problem you mention above - a group mistaken as a host. Not a
typo, but an easy enough mistake to make and took me a while to spot.
I've also tried to add a host to a [:children] section, but that does
at least give a decent enough error message IIRC.
I'm sure I'll get used to where to put things soon ;).
I am pretty sure I like things being explicit, and not mixing hosts and groups, since the file is easier to audit that way to see
if it is what you want it to be.
I like having anything in a group in one list, but that's clearly a
subjective preference.
OK, one more suggestion and then I promise to shut up ;), but if
you're aiming for explicit, perhaps [:children] is a little vague?
Maybe something like [:groups] would be better?
- Matt
OK, one more suggestion and then I promise to shut up ;), but if
you're aiming for explicit, perhaps [:children] is a little vague?
Maybe something like [:groups] would be better?
Implicit vs Explicit is different than bike shedding the word choice 
Subgroups is probably technically most accurate, though it's already established and I don't want the code littered with synonym logic.
--Michael