Can't call argless runner funcs from salt-api clients

[goodboy]

Description of Issue/Question

When I make the same runner call with salt-run versus pepper I get the following:

(envsalt)  >>> pepper --auth pam --username saltvirt --password saltvirt --client runner virt.next_host
{
    "return": [
        "Exception occurred in runner virt.next_host: Traceback (most recent call last):\n  File \"/home/tyler/repos/sal
t/salt/client/mixins.py\", line 392, in _low\n    data['return'] = self.functions[fun](*args, **kwargs)\nTypeError: next
_host() takes no arguments (1 given)\n"
    ]
}

(envsalt)  >>> sudo salt-run virt.next_host
17:06:10 [ 1865] [WARNING ] salt.loaded.int.runners.virt:66 'quiet' is deprecated. Please migrate to --quiet
sip-cannon
sip-cannon

Setup

master config is setup to use eauth:

# The external auth system uses the Salt auth modules to authenticate and            │
# validate users to access areas of the Salt system.                                 │
external_auth:                                                                       │
 pam:                                                                                │
   tyler:                                                                            │
     - .*                                                                            │
   saltvirt:                                                                         │
     - '@wheel'                                                                      │
     - '@runner'                                                                     │
     # should really make this a virt grains target                                  │
     - 'sip-cannon':                                                                 │
       - .*                                                                          │
     - '*':                                                                          │
       - 'test.*'                                                                    │
       - 'grains.*'                                                                  │
       # - virt.*                                                                    │
       # - test.*                                                                    │

I've tried debugging this but any log messages I insert near the line causing the error doesn't show up in either of the salt-master or salt-api console logs. Is there somewhere I can enable logging for this kind of thing in salt-api?

I already have:

# rest cherrypy config                     
rest_cherrypy:                             
  port: 8000                               
  ssl_crt: /etc/pki/tls/certs/localhost.crt
  ssl_key: /etc/pki/tls/certs/localhost.key
  debug: True           

in my master config.

Versions Report

Dependency Versions:
           cffi: 1.9.1
       cherrypy: unknown
       dateutil: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.9.5
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.13 (default, Dec 21 2016, 07:16:46)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.4.2
            ZMQ: 4.1.6

System Versions:
           dist:
        machine: x86_64
        release: 4.8.13-1-ARCH
         system: Linux
        version: Not Installed

[gtmanfred]

Thanks for reporting this, I have replicated the error, we will get this fixed.

Thanks, Daniel

[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.

[gtmanfred]

still relevant

[stale[bot]]

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