I'd do this without delegation, but with roles. I'd have one role that's 
parameterized with "instance name" , and have it applied 3 times to one host in 
testing and once (parameterized with host vars) per host in production.

Or even better, parameterize the role with list of mongo instances - then you'd 
be able to use the same play for tests and production.

Mike Trienis <[email protected]> napisał:
>Hi Michael, thank you for taking the time to respond!
>
>It's a bit of an unusual use case, so I am trying to understand if
>there is 
>a better way to solve the problem. 
>
>I am setting up mongo replication on two types of environments 
>
>   1. Single-instance with replication for testing purposes
>   2. Multi-instance with replication for production purposes 
>
>In the single-instance case there are three init scripts on one machine
>
>   - /etc/init.d/mongod-mongo1
>   - /etc/init.d/mongod-mongo2
>   - /etc/init.d/mongod-mongo3
>
>Starting all three services on instance A is a simple task for the
>single 
>instance topology
>
>- name: start all three mongodb service
>  shell: creates=/var/lock/subsys/mongod-{{ item.name }} 
>/etc/init.d/mongod-{{ item.name }} start
>  with_items:
>    - { name: mongo1, host: mongo1.example.com }
>    - { name: mongo2, host: mongo2.example.com }
>    - { name: mongo3, host: mongo3.example.com }

This would be just:

- service: name={{ item.name }} state=started
  with_items: mongo_instances

With something like:
mongo_instances:
- name: mongo1
- name: mongo2
- name: mongo3

In the test host's variables

>However, if we're dealing with a multi-instance topology, I would want
>to 
>start */etc/init.d/mongo1* on instance A, and */etc/init.d/mongo2* on 
>instance B, and */etc/init.d/mongo3* on instance C. Here is a a crappy 
>solution to help illustrate the problem.
>
>- name: start all three mongodb service
>  shell: ssh root@"{{ item.host}}"; creates=/var/lock/subsys/mongod-{{ 
>item.name }} /etc/init.d/mongod-{{ item.name }} start
>  with_items:
>    - { name: mongo1, host: mongo1.example.com }
>    - { name: mongo2, host: mongo2.example.com }
>    - { name: mongo3, host: mongo3.example.com }

For this you'd have to set the right instances in the right host's variables - 
the playbook could stay the same

>
>Thanks, Mike. 
>
>
>On Tuesday, 19 August 2014 11:38:21 UTC-7, Michael DeHaan wrote:
>>
>> " am running a playbook that connects to* remote host A*, and would
>like 
>> to know if it is possible to run a *delegate_to:* command on the
>*remote 
>> host* *A."*
>>
>> The delegate_to keyword is there to supply a different host to run on
>than 
>> one being traversed by Ansible's host loop.   If you are looping over
>the 
>> playbook on A, and want to run the command on A, you would leave off
>the 
>> delegate_to entirely.
>>
>> I'm perhaps not understanding the question though.
>>
>>
>>  
>>
>> On Tue, Aug 19, 2014 at 12:38 AM, Mike Trienis <[email protected] 
>> <javascript:>> wrote:
>>
>>> Hi All,
>>>
>>> I am running a playbook that connects to* remote host A*, and would
>like 
>>> to know if it is possible to run a *delegate_to:* command on the
>*remote 
>>> host* *A. *The use case is that I have two different types of 
>>> environments, one that relies on /etc/hosts to resolve the domain,
>and 
>>> another type of environment that uses DNS to resolve the domain. So
>if I 
>>> run delegate_to: "my.host.com", it will either resolve to 127.0.0.1
>in 
>>> the case of a single instance, or it will resolve the public IP
>address in 
>>> the case for a remote machine. 
>>>
>>> - name: start all three mongodb services
>>>   delegate_to: "{{ item.host }}"
>>>   shell: creates=/var/lock/subsys/mongod-{{ item.name }} 
>>> /etc/init.d/mongod-{{ item.name }} start
>>>   with_flattened:
>>>     - replication_servers
>>>
>>> Any help would be appreciated
>>>
>>> -- 
>>> 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:>.
>>> To post to this group, send email to [email protected] 
>>> <javascript:>.
>>> To view this discussion on the web visit 
>>>
>https://groups.google.com/d/msgid/ansible-project/c196e116-ce13-4ca6-b169-f01fac80ff3c%40googlegroups.com
>
>>>
><https://groups.google.com/d/msgid/ansible-project/c196e116-ce13-4ca6-b169-f01fac80ff3c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
Wysłane za pomocą K-9 Mail.

-- 
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].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/62a92b11-f634-4322-92b8-7556d73ac0c4%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to