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 <peter.geh...@appdynamics.com>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 > <mich...@ansibleworks.com>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 <pmis...@gmail.com>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:pmis...@gmail.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 ansible-project+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Michael DeHaan <mich...@ansibleworks.com> >> 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 ansible-project+unsubscr...@googlegroups.com. >> 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 ansible-project+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
