All of this pseudo-academic confusing language is going to prevent most everyone here in holding a conversation with you.
Your conclusion that you somehow need 100 inventory files is completely strange -- nobody does that. Concepts like a "service axis" and "ambigious localhosts" are things you are creating in your own mind, they are not Ansible concepts, and I think you're really making this all too hard. Apologies if I'm seeing an educational empasse, but all of the above is totally not neccessary -- if you can't reset back to basic concepts and try to solve simple problems simply, perhaps it's not for you? On Thu, Nov 28, 2013 at 4:25 PM, Paul Sokolovsky <[email protected]> wrote: > Hello, > > On Thu, 28 Nov 2013 15:31:17 -0500 > Michael DeHaan <[email protected]> wrote: > > > "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:" > > > > Nope, both plays are run, however the hosts are limited down to > > things in the service1 and vagrant groups. > > > > Your localhost box is selected in the service2 play because devel has > > vagrant has localhost. > > > > Working as designed. > > ... or in other words, Ansible doesn't do "hierarchical", symbolic > matching, just reduces all symbolic expressions to host sets and > does set arithmetic on them - well, that was said in the original mail, > and I don't argue it should do it differently. > > The original question still remains - how to "tell" Ansible that > "localhost:&service1" and "localhost:&service2" are two "different" > localhosts and it should discriminate tasks on "service1 vs > service2" part, not unify all tasks together based on "localhost" part? > > My thinking led me to an idea that host inventory files for ambiguous > hosts (devel hosts in this case) need to be split per "service" axis > (just like I already did by development/production axis). That will get > rid of ambiguity - for each localhost, there will be a single service in > Ansible's scope. Bad news is that it's not DRY - for 100 services, > there will be need for 100 inventory files ;-(. "Good" news is that > they are all similar, so can be generated/maintained by a meta-level > script. I still wonder if there's a better solution. > > > > -- > Best regards, > 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.
