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

-- 
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.

Reply via email to