And then I reread and, right after I sent, realize that they have similarities, but are totally different.
On Wed, Nov 27, 2013 at 9:02 PM, Peter Gehres <[email protected]>wrote: > If I am understanding this correctly, > https://github.com/ansible/ansible/issues/4505 is what he was expecting, > as I was. > > > On Tue, Nov 26, 2013 at 5:56 AM, Michael DeHaan > <[email protected]>wrote: > >> First question, >> >> ansible --version ? >> >> Second point >> >> "I obviously won't argue that Ansible should do hierarchical matching." >> >> It completely does. >> >> I'm having difficulty drawing the lines in between your lines of >> questioning as you're not showing full ansible command line executions and >> playbook snippets for your playbook runs. >> >> If you can show that, with specifically which ones you think work and do >> not, I'd understand better. >> >> >> >> >> >> >> >> >> On Mon, Nov 25, 2013 at 11:26 PM, Paul Sokolovsky <[email protected]>wrote: >> >>> Hello, >>> >>> I'm trying to encode following host schedule into Ansible inventory: >>> >>> 1. There're multiple distinct services. >>> 2. Each service is implemented by production host, staging host, and >>> unlimited number of (on-demand) development hosts. >>> 3. Production and staging hosts are all distinct and mostly static. >>> 4. Devel hosts are more interesting. They may be implemented as Vagrant >>> VM (== localhost) or a random EC2 instance. What's more interesting is >>> that any such devel host can run any service (not at the same time). >>> >>> So, I;m trying to encode that in terms of Ansible host groups. Before I >>> even start, I consider that by real-world security constraints it's >>> nice to split inventory along production/development axis. So, I came >>> with something like (staging stuff not included to make it less >>> cumbersome): >>> >>> === hosts_prod === >>> [service1] >>> service1.ip.com >>> [service2] >>> service2.ip.com >>> [prod:children] >>> service1 >>> service2 >>> === hosts_devel === >>> [vagrant] >>> localhost >>> [ec2-devel] >>> ec2-1-2-3-4.compute-1.amazonaws.com >>> [devel:children] >>> vagrant >>> ec2-devel >>> [service1:children] >>> devel >>> [service2:children] >>> devel >>> =========== >>> >>> Of course using "-i hosts_devel -l localhost" is ambiguous, so >>> instead I use "-i hosts_devel -l 'service1:&vagrant'" (i.e. >>> "perform operation on something which is (assume so) service1 >>> and backed by vagrant"). >>> >>> However, when I have a play with "- hosts: service2", it also matches. >>> What I "would expect" is that Ansible uses hierarchical set algebra >>> (aka class inheritance hierarchy) to test matching, and as service1 was >>> never said to be contained in service2 (aka service1 never inherited >>> from service2), then Ansible should not match them. Well, that's not >>> what happens - Ansible uses just flattened-out set arithmetic, >>> immediately reduces 'service1:&vagrant' to (localhost), then service2 to >>> (localhost, ec2-1-2-3-4.compute-1.amazonaws.com), then intersects them. >>> >>> I obviously won't argue that Ansible should do hierarchical matching. >>> But if it can't, what's the best approach to encode and maintain host >>> schema as described at the beginning of the email? Of course, with >>> these efforts I'm shooting for DRY (don't repeat yourself) approach. >>> >>> >>> Thanks, >>> Paul mailto:[email protected] >>> >>> -- >>> 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]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Michael DeHaan <[email protected]> >> CTO, AnsibleWorks, Inc. >> http://www.ansibleworks.com/ >> >> -- >> 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]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Peter Gehres > Site Reliability Engineer | AppDynamics, Inc. > www.appdynamics.com | AS62897 > -- Peter Gehres Site Reliability Engineer | AppDynamics, Inc. www.appdynamics.com | AS62897 -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
