" the 'copy' module will report an 'ok' status and *not* copy in the file, despite the fact that the file definitely did not exist when the task was run. "
I'm highly skeptical here but it's not quite fair for me to claim server gremlins without first using the server gremlins detector, which I don't have. Can you see if you can get to the bottom of why it is happening? On Mon, Mar 17, 2014 at 1:29 PM, David Banks <[email protected]> wrote: > Hey there, > > I am spawning some VMs using vagrant (CentOS 6.5 images) and copying a > file to them. I only want to copy the file if it does not already exist, > so that I can repeatedly run my playbooks against the host. > > My copy task looks like this: > > - name: Upload the default iptables configuration > copy: src=iptables.cf dest=/etc/sysconfig/iptables force=no > sudo: yes > > Roughly every 1 in 4 runs -- when reproducing on a fresh VM using "vagrant > destroy -f myvm; vagrant up myvm; ansible-playbook -i myinventory > playbook.yml" -- the 'copy' module will report an 'ok' status and *not* > copy in the file, despite the fact that the file definitely did not exist > when the task was run. The rest of the time the task will correctly report > a 'changed' status and correctly copy the file. > > I was unable to reproduce this when running against localhost. However, > the behaviour is not dependent on the choice of destination file. I can > try "/tmp/nonexistent-file-i-made-up" and it will reproduce with the same > frequency. This makes me think that it's not due to a timing issue in the > VM boot, as was my first thought. > > I have no idea why this would happen, or how I can debug further, does > anyone have an idea? > > I am working around it by doing an explicit check before: > > - name: Check for iptables configuration existence > action: stat path=/etc/sysconfig/iptables > register: iptables_stat > > - name: Upload the default iptables configuration > copy: src=iptables.cf dest=/etc/sysconfig/iptables > sudo: yes > when: not iptables_stat.stat.exists > > This doesn't have the same issue, although it does have the obvious race > condition. > > Dave > > -- > 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/46108fc7-d0b7-4aa8-ac58-077a527cac42%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/46108fc7-d0b7-4aa8-ac58-077a527cac42%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAEVJ8QNzwLnh2tpj4RVbM0b7CK1V-jbWTD-otiHi2Yt_pceT2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
