Add the strip-component feature to the Ansible unarchive module

[inbay]

Proposal: Add the strip-component feature to the Ansible unarchive module

Author: Kyle Manel <@inbay>

Date: 2019-09-03

• Status: New
• Proposal type: (module enhancement)

Motivation

I often need to add additional operations within Ansible to provide this function; Which is already a feature with tar using --strip-components as below; shell: tar -xf {{ DIR }}/{{ TAR.GZ_PKG }} --strip-components=1 -C {{ WORKING_DIR }}

Problems

By providing this addition to the unarchive module, it will provide direct capability to reduce the work being done if only a sub-set of an entire tar.gz file is necessary, and remove the necessity to clean the extracted archive of unnecessary files.

• Problem #1 To extract only a sub-directory within a tar(.gz) file
• Problem #2 To work in capacity restricted locations where extracting the entirety of a tar.gz file is not possible.

Solution proposal

By adding the feature provided by the --strip-components switch for the tar command, this will provide this feature, instead of requiring code to be written in shell: which is specific to the implementation, and not universal.

By providing this feature it improves the read-ability of the Ansible playbook and provides less complexity to the operations so that steps can be easily reproduced

Documentation (optional)

This will require a sub-task added to the Ansible unarchive (presumably) module; strip-component: 'Remove the specified number of leading path elements. Pathnames with fewer elements will be skipped.'

[agaffney]

This should just be a feature request (or even a PR) in the ansible/ansible project. Proposals are for far-reaching changes to Ansible itself. Also, it looks like you can already do this with unarchive by using extra_opts.

[dagwieers]

And for unarchive it is more complicated, we cannot add options that only affect gtar and doesn't have effect on unzip...

[inbay]

@agaffney In hind sight I would have thought that as well. The below document specifies this explicitly at the bottom, which specifies 'Requesting a feature' with steps to submit a proposal at the bottom; https://docs.ansible.com/ansible/2.3/community/reporting_bugs_and_features.html

In any case I had not acknowledged that there were ulterior locations to provide feature requests, for modules, core, ui, etc, as I had expected them to be triaged from here from the (lack-of) description on the site above.

I had been curious on the 'extra_opts' field, and will review this on my own time. Thank-you.

[agaffney]

That document is a bit misleading. The proposals process makes sense for Ansible-wide features, but not features in a particular module.

[jamescassell]

I was also under the impression that RFEs were supposed to be proposals, which is why I only ever send PRs. The bug template definitely makes it seem that's the case, last I checked.

[bcoca]

closing as per above, this is a feature request, does not really belong in proposals