On Tuesday, March 3, 2020 at 10:28:15 PM UTC-6, Vladimir Botka wrote:
>
> On Tue, 3 Mar 2020 19:36:11 -0800 (PST) 
> Stephen Gevers <[email protected] <javascript:>> wrote: 
>
> > solr is not a host, it is a group.  It just happens to be a group of one 
> > host.  Likewise, dmgr is a group of one host.  Consider the following 
> > inventory: 
> > 
> > [dmgr] 
> > host1.example.com 
> > 
> > [solr] 
> > host2.example.com 
>
> This justifies the developer's conclusion: 
> https://github.com/ansible/ansible/issues/67410#issuecomment-590919487 
>
>   "This is a race condition between two different hosts modifying the same 
>   shared file, which is asking for trouble. There isn't much we can do in 
>   code to fix this." 
>

I still haven't figured out why this justifies the developer's conclusion. 
 From the output, the task that creates the file clearly happens before the 
task that checks for its existence.  The output included in the case shows 
the order in which things happen:

TASK [create the file on dmgr] *************************************************
skipping: [SOLR REDACTED]
changed: [DMGR REDACTED]

TASK [stat the file from both] *************************************************
ok: [SOLR REDACTED] 

ok: [DMGR REDACTED] 


>From the output, it seems that the stat task doesn't get kicked off until 
the "changed" result completes from the create task above it.   Further, 
I'm basing this on a rather old (2014) Stack Overflow response which 
states: 
As mentioned before: By default Ansible will attempt to run on all hosts in 
parallel, but task after Task(serial).
So I was assuming that based on the order of the playbook, the stat task 
couldn't be started until after the creation task completed.  If this 
playbook is causing a race condition, this may no longer be accurate.  

And in the same time, this reveals the problem in the code. The condition 
> is 
> true for both hosts. (I have no idea why "solr" reports "skipping") 
>
>   - hosts: dmgr:solr 
>
>     ... 
>
>     - name: create the file on dmgr 
>       shell: 'echo "Hello World" > {{ shared_dir }}/testfile' 
>       when: "'dmgr' in group_names" 
>
>     TASK [create the file on dmgr] 
>     ************************************************* 
>     skipping: [SOLR REDACTED] 
>     changed: [DMGR REDACTED] 
>

I'm guessing that my choice of using SOLR to indicate both host and group 
is confusing.  Given the above inventory file, the skipping line would 
 probably more accurately be 
skipping: [host2.example.com] and is skipping because "dmgr" is not in 
group_names for host2.


> Anyway, the solution is to fix the conditions and limit the deletion and 
> creation of the file to the host from one group only. For example 
>
>   - name: Remove the file from solr 
>     file: 
>       path: "{{ shared_dir }}/testfile" 
>       state: absent 
>     when: inventory_hostname in groups.solr 
>
>    ... 
>
>   - name: create the file on dmgr 
>     shell: 'echo "Hello World" > {{ shared_dir }}/testfile' 
>     when: inventory_hostname in groups.dmgr 
>
> As a side-note, it's possible to use "copy" instead of "shell" 
>
>   - name: create the file on dmgr 
>     copy: 
>       content: 'echo "Hello World"' 
>       dest: "{{ shared_dir }}/testfile" 
>     when: inventory_hostname in groups.dmgr 
>
> HTH, 
>
>         -vlado 
>

The problem the solution is that it doesn't solve the actual problem.  This 
is just a simple playbook that illustrates the issue.  In the actual 
playbook, host1 is running a command that is exporting a file from a store 
that only exists on host1.  host2 needs to import that file.  My solution 
was to run the command against host1 and export the file to the shared file 
system.  Then run the import on host2.  The import has the effect of 
removing the file from the shared file system.  I had it all working until 
I added a "removes" option to the shell task that did the import.  Then the 
removes indicated the file wasn't there and skipped the import.  That's 
when I opened the case.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/9195d93d-ee09-43f5-8c80-363ddec63dcf%40googlegroups.com.

Reply via email to