Salt: Inconsistent behavior from file.find (regression/bug?)

[ferricoxide]

Description of Issue/Question

Trying to construct a list of files to feed to another salt module to deal with. When I run file.find from the CLI, I get expected behavior but when I run from within an SLS file, it seems like the type option gets ignored

Setup

Original state-file was originally authored and tested under salt 2016.3.4.

Today, while testing my larger formula on a test-host, the first run succeeded but subsequent runs failed. My larger formula includes an operation that does a yum update -y. The first run apparently changed the salt-minion version prior to the (idempotency-test) re-run. During the re-run, the previously-working state-file stopped working. Instead, the formula emitted failed: Problem running salt function in Jinja template: Cannot perform string replacements on a binary file: /etc/modprobe.d; errors when rendering the jinja in the find-enabled states.

Steps to Reproduce Issue

When executed from command-line:
~
sudo salt-call --local file.find '/etc/modprobe.d' type=f
local:
- /etc/modprobe.d/lockd.conf
- /etc/modprobe.d/mlx4.conf
- /etc/modprobe.d/nousbstorage
- /etc/modprobe.d/tuned.conf
~
However, when run from within a state-file:
~
{%- set modFiles = salt'file.find' %}
{%- set testarr = " ".join(modFiles) %}
find_test:
cmd.run:
- name: 'echo "Array-contents: {{ testarr }}"'
- cwd: /root
~
I get the output:
~~~

local:

      ID: find_test
Function: cmd.run
    Name: echo "Array-contents: /etc/modprobe.d /etc/modprobe.d/lockd.conf /etc/modprobe.d

/mlx4.conf /etc/modprobe.d/nousbstorage /etc/modprobe.d/tuned.conf"
Result: True
Comment: Command "echo "Array-contents: /etc/modprobe.d /etc/modprobe.d/lockd.conf
/etc/modprobe.d/mlx4.conf /etc/modprobe.d/nousbstorage /etc/modprobe.d/tuned.conf"" run
Started: 00:40:52.930714
Duration: 5.456 ms
Changes:
----------
pid:
4426
retcode:
0
stderr:
stdout:
Array-contents: /etc/modprobe.d /etc/modprobe.d/lockd.conf /etc/modprobe.d/mlx4.conf
/etc/modprobe.d/nousbstorage /etc/modprobe.d/tuned.conf

Summary for local

Succeeded: 1 (changed=1)

Failed: 0

~~~
I created a test-state so I could see why my "real" state was failing jinja errors (see Setup section for exact error-string).

Versions Report

~~~
Salt Version:
Salt: 2016.11.0

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.7.2
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
Python: 2.7.5 (default, Nov 6 2016, 00:28:07)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4

System Versions:
dist: centos 7.2.1511 Core
machine: x86_64
release: 3.10.0-514.el7.x86_64
system: Linux
version: CentOS Linux 7.2.1511 Core
~~~

[wolfpackmars2]

try salt['file.find']('/etc/modprobe.d', type='f') or __salt__['file.find']('/etc/modprobe.d', type='f')

the single quote is moved from before the t in type to after the = sign

[ferricoxide]

Cool. I'll give the moving the ' from around the type=f to around just the f, tomorrow.

[ferricoxide]

Alright. Moving the ticks to surround _just_ the option-value – rather than around the option-pair – fixes my issue.

Any chance the documentation could be updated? To me, at least, it wasn't clear what the proper method for specifying the values in the context of an SLS file was (and, that it worked in 2016.3 but failed in the stricter 2016.11, muddied things further).

At any rate: thanks for the usage-correction!

[Ch3LL]

@ferricoxide we can definitely get this fixed up in docs. will label as documentation bug Thanks

[wolfpackmars2]

Not sure why it would have worked in the earlier version. salt['file.find']('/etc/modprobe.d', 'type=f') is a python statement. You were attempting to pass a keyword argument (kwarg) type with the value 'f'. By surrounding the whole argument with a quote, you were passing a positional argument (arg) with the value 'type=f', which couldn't be processed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[ferricoxide]

This probably shouldn't be marked stale: should either be marked "fixed" or still needs to be fixed. Given the last communication from @Ch3LL I'd assumed it was in the fix-pipeline at the end of 2016.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[Ch3LL]

@ferricoxide im revisiting this issue after a couple years so can you remind me what you need cleared up in the docs? Re-reading the issue it seems you were trying to just quote the kwargs which should not ever be quoted, and would be surprised if that was indeed working previously.

[ferricoxide]

To be honest, I haven't had a chance to revisit this since you added the tags. I'd assumed, at that point, that the documents were going to be update and the issue closed. Was only the stale-bot's notification that the issue was still open that I became aware that it wasn't closed.

[Ch3LL]

so just to be clear the only issue was making sure not to quote the kwarg?

[ferricoxide]

Sorry. Yeah, that's my recollection. =)

[Ch3LL]

cool thanks for clarifying. i'll assign myself this and see where the best place is we could document this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.