Implement 'pathglob' filter plugin and lookup plugin

[charlienewey]

ISSUE TYPE

Feature Pull Request

COMPONENT NAME

• pathglob filter plugin
• pathglob lookup plugin

SUMMARY

In response to comments in #17136 and #17269, alternative pathglob filter and lookup plugins to match both files and directories, or directories only (if specified in glob, e.g. {{ "/some/path/*/" | pathglob}}).. This feature is suggested in #17480.

[charlienewey]

@bcoca I noticed you closed the issues referenced in this PR today - is there any movement on accepting this?

[tknerr]

@bcoca @charlienewey would definitely be nice to have a dirglob and / or pathglob in addition to the fileglob filter and lookup plugins.

Example here:

- name: List all currently configured nodes in nodes directory
  command: find /var/lib/jenkins/nodes -mindepth 1 -maxdepth 1 -type d -exec basename {} \;
  register: existing_nodes
  changed_when: False

- name: Remove all unmanaged slave nodes from the plugins directory
  shell: rm -rf /var/lib/jenkins/nodes/{{ item }}
  with_items: "{{ existing_nodes.stdout_lines }}"
  when: item not in "{{ jenkins_slave_nodes | default([]) | map(attribute='name') | list }}"

Where I'd rather like to write simply:

- name: Remove all unmanaged slave nodes from the plugins directory
  shell: rm -rf /var/lib/jenkins/nodes/{{ item | basename }}
  with_dirglob:
    - /var/lib/jenkins/nodes/*
  when: "{{ item | basename }}" not in "{{ jenkins_slave_nodes | default([]) | map(attribute='name') | list }}"

[calfonso]

@charlienewey is there any reason you can't execute a shell command to find the dirs and files, register the output, and reference the registered in the next task?

[charlienewey]

@calfonso That would be inconsistent behaviour, no? The fileglob module does the same thing for files, I'm just making the behaviour consistent. Besides, it's inconvenient to do the above as you mentioned.

[bcoca]

I would prefer each plugin in it's own PR, mostly cause filter is much easier/saner to merge.

filter:

• implementation is fine, we should have strong docs letting user know the paths resolve ON CONTROLLER.

lookup:

• docs issue, same as filter .. but more
• fileglob is a bit murky and this one has same issues, when it is a relative lookup going through dwim ... people have different expectations from what really happens. There are many diff ways people expect it to work but only one real way it does. This can either be VERY clearly stated in docs or use an option to alter between the diff expectations.

[djmattyg007]

@calfonso thatcs really awkward to do, and find is a very unintuitive command. On the other hand, most people generally understand globbing a lot more easily. I'd definitely appreciate this being in the core.

[maxamillion]

Hi!

Thanks very much for your submission to Ansible. It sincerely means a lot to us that you've taken time to contribute.

Unfortunately, we're not sure if we want this feature in the program, and I don't want this to seem confrontational. Our reasons for this are because we already have the filetree lookup plugin that satisfies this use case.

https://docs.ansible.com/ansible/latest/plugins/lookup/filetree.html

However, we're absolutely always up for discussion. Since this is a really busy project, we don't always see comments on closed tickets, but want to encourage
open dialog. You can stop by the development list, and we'd be glad to talk about it - and we might even be persuaded otherwise!

• https://groups.google.com/forum/#!forum/ansible-devel

In the future, sometimes starting a discussion on the development list prior to implementing a feature can make getting things included a little easier, but it's not always necessary.

Thank you once again for this and your interest in Ansible!