trying to write a tar module/action_plugin

Archives Ansible Project
1

Hi all. I sometimes like to copy tarfiles to hosts and unpack them with ansible. It’s getting a little unwieldy so I thought I’d try to write a module to do it so I could just specify a task like

tar: src=foo.tgz dest=/var/lib/foo

and be done with it

After much confusion and reading of the source, It appears that I’d want to write both a module and an action plugin. The action plugin would copy the tar file from my server to the host being managed and the module would unpack it once there.

Am I right about that?

Can I call another action plugin from my action plugin? IE can I call the copy action plugin to transfer the files? Or is there another way I can re-use that code?

I know a lot of folks do rsync from a local_action to handle things like this, but I want to know when things are changed or not. I want those pretty little OK and Changed columns in my ansible-playbook output. If I change one file in a collection of static files, I want to know that change made it to each host.

Maybe a better idea is just to write a module that unpacks tar files on the destination host and relies on me using the copy action before hand. Less cool, but a lot easier to develop.

Any suggestions welcome.

Thanks!

-Dylan

2

you can look at the new synchronize plugin waiting to be merged (rsync) which also uses a action_plugin

3

This may be a dumb question, but where would I find the new synchronize plugin? Or do I wait for it to be merged?

4

Normally new/submitted modules appear as pull requests.

this one is at:
https://github.com/ansible/ansible/pull/4167

5

Thanks!

6

The “copy” module is also a good example of a plugin that calls other modules, in this case “file”.

Would be super interested in a module.

we should probably call it “unarchive” maybe?

7

One note about the copy-over-and-unarchive-automatically thing: there
are use cases where one is unarchiving something which was downloaded
directly to the remote host, and thus it would be useful to support
purely remote operation also.

8

Hi,

just a thought, but what would be the best way to ensure idempotency for this unarchive module ?

As I understand it, “unarchive” would :

  • transfer a src=*.tgz to the hosts
  • unarchive the file into the dest directory

so how would you check for the similarity of the unarchived src and the previously unarchived content of dest (unarchived in a previous ansible run) ?

9

I’ve had a couple of ideas:

  1. gnu tar (and possibly others) has a --diff option which will compare a tar archive to a directory. This is a bit unwieldy. It doesn’t detect files added to the directory that aren’t in the tarball. Portability depends on how widespread this feature is. (that reminds me, a future feature would be similar to the --delete flag in rsync)

  2. One could unpack the tarball into a tmp directory and compare the tmp and dest directories This is inefficient and would fail if the unpacked archive was bigger than the tmp dir. But it does what you want done.

  3. Look at any python libs that do tar stuff. If they’re in core python and they support something like --diff in the binary, I’m happy dude. Otherwise, it should be pretty easy to implement a --diff type functionality. If tar in python requires the user to install special libs, that sucks.

  4. not checking actually doesn’t violate idempotency - If the destination already matches the tar and you unpack the tar, the destination hasn’t changed. This one is lame because you don’t know when there’s been any changes.

My plan is to start with option 4, which will give me the simplest functional tar module/action_plugin. Then I’ll try option 3 unless folks suggest otherwise.

10

I’ve just finished the barest of bare-bones tar/unarchive modules

http://github.com/pileofrogs/ansible_unarchive

It copies gzipped tar files to your host and unpacks them where you say. It does NOTHING else. More features will be added if people want them. The readme on the github above lists a lot of ideas. I’ll make a pull request when this is more usable.

I wasn’t sure of the best way to host this module in it’s present state. It’s not at all ready for a pull request, but I wanted to get started pushing stuff out to the world. Any advice on that would be great.

And of course, any advice on this unarchive module would be fantastic.

Thanks everyone
-Dylan