Michael,
would you consider a patch to the ini inventory to allow putting certain hosts or groups in a particular group?
e.g. something like
[development]
-dev-
[applicationservers: children]
app-*
Before you tell me to use group_by, the reason I’m looking for this functionality in the Inventory, is to be able to use it in patterns, and to the --limit option.
Serge
Doesn’t make any sense, because inventory defines what the names of the host actually are.
I understood what you mean. That would be a more than trivial patch, with code that implements that after the inventory is build whilst remembering the patterns it encountered, but I don’t see why it would be impossible?
It is unfortunately logically confusing.
Inventory names hosts, this would not specify what hosts were real out of an infinite number.
This is about a pattern matching the hosts already in the inventory, and add them to a specific group, not about generating an undefined set of hosts.
mvg,
Serge van Ginderachter
Right, but you’re doing it in the inventory file.
If you want to pattern match specific hosts, there is already
hosts:foo
But that doesn’t allow me to configure variables for the group I want to generatein a group vars file.
Either way I’m going to switch to inventory scripts to do my thing.
mvg,
Serge van Ginderachter
Yes, inventory scripts were defined to allow people to build systems for when they disagreed with the default.
Please do.
I just did this with group_by (define groups in inventory but assign them dynamically)
but this gets clunky and you have to be careful with order (group/server pattern overlaps). I was about to start my own inventory plugin, but I’m happy if you beat me to it.
I just did this with group_by (define groups in inventory but assign them
dynamically)
I know, but then you can't use that with the --limit option to target a
part of your infra
but this gets clunky and you have to be careful with order (group/server
pattern overlaps). I was about to start my own inventory plugin, but I'm
happy if you beat me to it.
Don't hold your breath, that plugin will be very specific to my
environment, I don't expect it to be very usefull for general use. I'll
try to make it as generic as possible though.
The idea is to partametrize the environment as this:
- organise in group, parent child, as in the current ini
- define a set of nodes (a list eg [1,2] bit could be anything
- define a set of environments (dev, test, prod, optionally eg loadtest for
particular applications)
- define a series of applications within a particular group
I could go an define a template for hostname creation, eg
{app}-{env}-{node}, yielding
tomcat-test-1
tomcat-test-2
tomcat-prod-1
..etc..
Right now I'm still thinking about how to organise this, and which config
format to use.
(BTW: what was the reason in 0.6 to switch from yaml to ini?)
Serge
There wasn't really a switch from Yaml to INI, there was the decision to not support more than one inventory-file out-of-the-box, and the decision was to use the INI format because it is easier to use for new users.
The most important reason is that keeping two default formats feature-complete was more of a hassle than it was worth having the two formats around.
The rational was also that more advanced users would probably write their own inventory scripts anyway, so they might as well use the yaml inventory script which is an in-place replacement of what used to work before.
Not everyone agreed with using INI as the default (especially those that already were using yaml as a backend) but because of the yaml inventory script the impact is also not worth complaining about 