unarchive module: creates does not work

Archives Ansible Project
1

I am using ansible 1.8 devel

I have a task like this one:

  • name: something
    unarchive: creates=some_file src=src_file.tar.gz dest=dest_dir

Archive is always copied, even if some_file exists
Browsing through source code, I saw that there is a runner/action_plugins/unarchive.py
file, which makes me think that there is an action named “unarchive”.
In this file, there is no creates option.
Maybe some collision between action and module?

Please, could you explain me what is wrong?

2

I believe it may copy the file and only crack it open if it doesn’t exist.

Regardless, please file a bug report with steps to reproduce so someone can take a look.

(Code-wise, if you want to take a look, this is dealt with lib/ansible/runner/action_plugins/unarchive.py – the actual ansible module is only
the last bit of it)

Thanks!

3

I submitted a pull request to fix this issue: https://github.com/ansible/ansible/pull/8116
The reason is that the creates option is checked in /library/files/unarchive after it’s already been copied in /lib/ansible/runner/action_plugins/unarchive.py.
Simply shifting the check to the action_plugin prevents an unnecessary file transfer.

4

Has this been addressed in 1.8.2? I am unable to get the creates parameter to work, and am wondering if I’m doing something wrong.

If I edit /usr/share/pyshared/ansible/runner/action_plugins/unarchive.py (ansible installed via PPA) and add

`
print module_return.result

`

after lines

`
module_return = self.runner._execute_module(conn, tmp, ‘stat’, module_args_tmp, inject=inject,
complex_args=complex_args, persist_files=True)

`

it outputs

`
{u’msg’: u’unsupported parameter for module: creates’, u’failed’: True}

`

which makes me think something is rather wrong.

5

The code seems to have gone in quite a while ago. It seems to work
for me and I'm not getting the same debugging output with 1.8.1 and
current devel.

I don't believe that there was anything in 1.8.2 that would be
different from both of those.

The fact that it's saying that creates unsupported when it's calling
the piece of hte module that run remotely implies to me that ansible
is finding an older module library on your system. Do you by chance
have an older checkout somewhere or an older distro package?

-Toshio

6

Thanks for the suggestion. But to my knowledge I don’t have any other checkouts or packages installed. I even ran sudo apt-get purge ansible, and before I reinstalled I

  • verified that find /usr/ -name '*ansible*' output nothing
  • deleted /etc/ansible on the control machine
  • deleted ~/.ansible on both the control machine and the remote host

However I have the same result; when unarchive.py tries to stat the file I’ve passed as the creates parameter to unarchive, the stat fails as in my previous message.

7

Pardon the reply to myself but I’ve stumbled upon a lead. If I use YAML module parameters, like

`

  • unarchive:
    src: ‘file.zip’
    dest: ‘/foo’
    creates: ‘/foo/bar’

`

then the creates check never works, as described previously (the unarchive itself still works but it doesn’t check for file existence so it always unarchives). But if instead I use key=value module parameters, like

`

  • unarchive: src=‘file.zip’ dest=‘/foo’ creates=‘/foo/bar’

`

then it works fine. Bug?

8

Yeah, that would be a bug. Probably best to open a bug report on github so we can look into it and not forget.

-Toshio

9

are you using variables in both complex syntax and inline syntax?
can you post the actual task where you use that module?
also, are you using copy=false?

10

are you using variables in both complex syntax and inline syntax?

Not sure I’m well enough versed in Ansible terminology to understand the question. If by variables in complex syntax you mean accessing nested data structures as in http://docs.ansible.com/playbooks_variables.html#accessing-complex-variable-data then no. But if that’s not what you mean then hopefully the following answers your question anyway.

can you post the actual task where you use that module?

Sure, with some file names changed to protect the innocent. The following task (inside a custom role) works for me, respecting the creates parameter:

`

  • name: extract project
    unarchive: src=‘project-{{ project_version }}.zip’ dest=‘/opt’ creates=‘{{ project_dest }}/README.txt’
    sudo: true

`

I also have a defaults/main.yml inside the role containing among other things the following:

`