On 12/20/13, 6:05 AM, Michael DeHaan wrote:
Does anyone rely on wildcard group match? If not, I'm more than happy
to change this.
We (Rackspace) rely heavily on wildcard group matching. We have a number
of inventories, broken down by region. Within each region there is a
number of cells, and within each cell there are a number of machine
roles that get turned into groups.
Lets take our ORD inventory.
ORD has cells c1, c2, and c3. Those all become groups, "c1, c2, c3".
Within c1 we have:
nova-compute
nova-api
nova-cells
etc...
Each of those are a role type. There is one or more actual hosts in each
of those role types.
c2 will have the same types, with different hosts within the types, so
on for the other cells.
We create groups that are a combination of the role and the cell in
which the hosts came from, e.g. the nova-compute set from c1 becomes
"c1-nova-compute", whereas the nova-cells set from c3 becomes
"c3-nova-compute".
The c1 group is just a collection of all the c1-<role> groups, same with
c2 being a collection of c2-<role> groups.
Our playbooks will often need to operate across all systems of a
particular role within an inventory, e.g. we need to operate on every
nova-compute node in a region.
hosts: "*-nova-compute"
That's how our playbooks look.
If we want to limit actions to a particular cell, we would add "--limit
c2" to our playbook execution line. That would reduce the available
inventory down to just things that exist in c2, and we can keep the
hosts: line as is with "*-nova-compute".
We could adjust how this is all done, if group globbing were to go away,
it would just require a fair amount of busy work.
-jlk
--
You received this message because you are subscribed to the Google Groups "Ansible
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
