Hello, Thanks for reply.
On Tuesday, November 26, 2013 3:56:54 PM UTC+2, Michael DeHaan wrote: > > First question, > > ansible --version ? > Initially this was tested with ansible 1.3.4 installed from Ubuntu PPA, I see that now 1.4 available via it and upgraded, but behavior is the same. > > 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. > Ok, I prepared this usecase as complete Ansible config: https://github.com/pfalcon/ansible-ambiguous-groups Having there one play with "- hosts: service1" and another with "- hosts: service2", one might expect that "ansible-playbook -i hosts_devel -l "service1:&vagrant" site.yml" would run only play with "- hosts: service1". However, both are run: --------- PLAY [service1] *************************************************************** TASK: [command echo "I wanna run for service1 only"] ************************** changed: [localhost] PLAY [service2] *************************************************************** TASK: [command echo "I wanna run for service2 only"] ************************** changed: [localhost] PLAY RECAP ******************************************************************** localhost : ok=2 changed=2 unreachable=0 failed=0 --------- Thanks, Paul > > > > > > > > > On Mon, Nov 25, 2013 at 11:26 PM, Paul Sokolovsky > <[email protected]<javascript:> > > 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] <javascript:> >> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Michael DeHaan <[email protected] <javascript:>> > 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.
