incompatible change in copy resultset in 2.4 #31477

philfry · 2017-10-09T15:07:08Z

ISSUE TYPE

Bug Report

COMPONENT NAME

copy

ANSIBLE VERSION

ansible 2.4.0.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/phil/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.13 (default, Sep  5 2017, 08:53:59) [GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]

CONFIGURATION

n/a

OS / ENVIRONMENT

n/a

SUMMARY

Between ansible 2.3.2 to 2.4.0 the results array of the copy module has changed in an incompatible way regarding path and dest.

STEPS TO REPRODUCE

ansible-playbook copy.yml

---
- hosts: localhost
  gather_facts: no
  tasks:
    - name: "cleanup"
      command: "rm -rf /tmp/ansibleresults"
      args:
        warn: no

    - name: "create directory structure"
      file: path={{item}} state=directory
      with_items:
        - /tmp/ansibleresults
        - /tmp/ansibleresults/src
        - /tmp/ansibleresults/dest

    - name: "create some dummy files"
      copy: content="I am a dummy file {{item}}" dest=/tmp/ansibleresults/src/myfile{{item}}
      with_items: [ 1,2,3,4 ]

    - name: "pre-copy a file"
      copy: src=/tmp/ansibleresults/src/myfile3 dest=/tmp/ansibleresults/dest/

    - name: "copy all source files"
      copy: src={{item}} dest=/tmp/ansibleresults/dest/
      register: t_copyresults
      with_fileglob:
        - /tmp/ansibleresults/src/*

    - name: "show attribute 'dest'"
      debug: var=item
      with_items:
        - '{{t_copyresults.results|map(attribute="dest")|list}}'

EXPECTED RESULTS

TASK [show attribute 'dest'] ***
ok: [localhost] => (item=/tmp/ansibleresults/dest/myfile4) => {
    "item": "/tmp/ansibleresults/dest/myfile4"
}
ok: [localhost] => (item=/tmp/ansibleresults/dest/myfile3) => {
    "item": "/tmp/ansibleresults/dest/myfile3"
}
ok: [localhost] => (item=/tmp/ansibleresults/dest/myfile2) => {
    "item": "/tmp/ansibleresults/dest/myfile2"
}
ok: [localhost] => (item=/tmp/ansibleresults/dest/myfile1) => {
    "item": "/tmp/ansibleresults/dest/myfile1"
}

ACTUAL RESULTS

TASK [show attribute 'dest'] ***
ok: [localhost] => (item=[u'/tmp/ansibleresults/dest/myfile4', Undefined, u'/tmp/ansibleresults/dest/myfile2', u'/tmp/ansibleresults/dest/myfile1']) => {
    "item": "[u'/tmp/ansibleresults/dest/myfile4', Undefined, u'/tmp/ansibleresults/dest/myfile2', u'/tmp/ansibleresults/dest/myfile1']"
}

The text was updated successfully, but these errors were encountered:

philfry · 2017-10-09T15:11:48Z

possible workaround:

    - name: "show attribute 'dest'"
      debug: var=item
      with_items:
        - '{{(t_copyresults.results|selectattr("path", "defined")|map(attribute="path")|list+t_copyresults.results|selectattr("dest", "defined")|map(attribute="dest")|list)|list|unique}}'

but... really?

ktosiek · 2017-11-06T17:05:37Z

Bisected this to f86ce09, seems to work on stable-2.3 (contrary to #25431)

jfbibeau · 2017-12-12T19:42:03Z

This is pretty much making Ansible 2.4 unusable for us. Confirmed that the resultset contains dest when copy task is changed, but contains path when the copy task is unchanged (ie: file already exists).

Example when file was copied:

ok: [192.168.11.10] => {
    "rpm_files": {
        "changed": true,
        "msg": "All items completed",
        "results": [
            {
                "_ansible_ignore_errors": null,
                "_ansible_item_result": true,
                "_ansible_no_log": false,
                "_ansible_parsed": true,
                "changed": true,
                "checksum": "e54a942de3eef088b5db7374b236c4ae8a61f04b",

                "dest": "/tmp/my.rpm",   <- Note the dest attribute, which is what's in ansible 2.2
...

Example when running the same task a 2nd time, this time with the file:

ok: [192.168.11.10] => {
    "rpm_files": {
        "changed": false,
        "msg": "All items completed",
        "results": [
            {
                "_ansible_ignore_errors": null,
                "_ansible_item_result": true,
                "_ansible_no_log": false,
                "_ansible_parsed": true,
                "changed": false,
                "checksum": "e54a942de3eef088b5db7374b236c4ae8a61f04b",

                 <--dest is missing here!!!

                "diff": {
                    "after": {
                        "path": "/tmp/my.rpm"
                    },
                    "before": {
                        "path": "/tmp/my.rpm"
                    }
                },
                "failed": false,
                "gid": 0,
                "group": "root",
                "invocation": {
                   ...
                    }
                },
                "item": "/src/path/to/my.rpm",
                "mode": "0644",
                "owner": "root",

                "path": "my.rpm",           <- dest was replaced by path?!

                "secontext": "unconfined_u:object_r:admin_home_t:s0",
                "size": 41525950,
                "state": "file",
                "uid": 0
...

jfbibeau · 2017-12-12T20:14:39Z

Looks like when the file needs to be copied, the copy action is the one that is fired.

However when the file checksum is the same, the file action is the one that is fired (to do any permission changes that are needed).

The file module seems to accept/return only path (which it says is an alias to dest), whereas the copy module seems to accept/return dest only.

I still don't see exactly where in commit f86ce09 this got changed, however the copy action was pretty heavily refactored and the diff is hard to read, so seems plausible the change was introduced there.

ktosiek · 2018-02-04T11:39:57Z

I've prepared a failing test case: ktosiek@d324c09

(cherry picked from commit 89ad40b)

ansibot added affects_2.4 This issue/PR affects Ansible v2.4 bug_report module This issue/PR relates to a module. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Oct 9, 2017

s-hertel removed the needs_triage Needs a first human triage before being processed. label Oct 13, 2017

ktosiek mentioned this issue Nov 6, 2017

bug - copy module returns 'path' or 'dest' based on changed status - not consistent #25431

Closed

ktosiek added a commit to ktosiek/ansible that referenced this issue Feb 4, 2018

Fix for ansible#31477: return 'dest' from copy when file wasn't changed

a0f7715

ktosiek mentioned this issue Feb 4, 2018

Fix #31477: "dest" missing in copy result #35702

Merged

abadger closed this as completed in #35702 Feb 9, 2018

abadger pushed a commit that referenced this issue Feb 9, 2018

Fix for #31477: return 'dest' from copy when file wasn't changed

c1c5433

(cherry picked from commit 89ad40b)

abadger pushed a commit that referenced this issue Feb 9, 2018

Fix for #31477: return 'dest' from copy when file wasn't changed

0ac4722

(cherry picked from commit 89ad40b)

abadger pushed a commit that referenced this issue Feb 9, 2018

Fix for #31477: return 'dest' from copy when file wasn't changed

89ad40b

ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 7, 2018

ansible locked and limited conversation to collaborators Apr 26, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

incompatible change in copy resultset in 2.4 #31477

incompatible change in copy resultset in 2.4 #31477

philfry commented Oct 9, 2017

philfry commented Oct 9, 2017

ktosiek commented Nov 6, 2017

jfbibeau commented Dec 12, 2017

jfbibeau commented Dec 12, 2017

ktosiek commented Feb 4, 2018

incompatible change in copy resultset in 2.4 #31477

incompatible change in copy resultset in 2.4 #31477

Comments

philfry commented Oct 9, 2017

ISSUE TYPE

COMPONENT NAME

ANSIBLE VERSION

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

philfry commented Oct 9, 2017

ktosiek commented Nov 6, 2017

jfbibeau commented Dec 12, 2017

jfbibeau commented Dec 12, 2017

ktosiek commented Feb 4, 2018