salt: pip.installed state not found

salt master:

root@salt:/srv# salt-call --versions
                  Salt: 2015.5.3
                Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
                Jinja2: 2.7.2
              M2Crypto: 0.21.1
        msgpack-python: 0.3.0
          msgpack-pure: Not Installed
              pycrypto: 2.6.1
               libnacl: Not Installed
                PyYAML: 3.10
                 ioflo: Not Installed
                 PyZMQ: 14.0.1
                  RAET: Not Installed
                   ZMQ: 4.0.4
                  Mako: 0.9.1
               Tornado: Not Installed
 Debian source package: 2015.5.3+ds-1trusty1

minion:

root@m1:~# salt-call --versions
                  Salt: 2015.5.3
                Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
                Jinja2: 2.7.2
              M2Crypto: 0.21.1
        msgpack-python: 0.3.0
          msgpack-pure: Not Installed
              pycrypto: 2.6.1
               libnacl: Not Installed
                PyYAML: 3.10
                 ioflo: Not Installed
                 PyZMQ: 14.0.1
                  RAET: Not Installed
                   ZMQ: 4.0.4
                  Mako: Not Installed
               Tornado: 4.2.1
 Debian source package: 2015.5.3+ds-1trusty1

State file (snipped to minimal):

util-pkgs:
  pkg.installed:
    - names:
      - python-pip

pip-utils:
  pip.installed:
    - names:
      - awscli
    - require:
      - pkg: python-pip

For some reason salt is not able to use pip anymore…

KeyError: 'pip.installed'
Traceback (most recent call last):
  File "/usr/bin/salt-call", line 11, in <module>
    salt_call()
  File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 227, in salt_call
    client.run()
  File "/usr/lib/python2.7/dist-packages/salt/cli/call.py", line 69, in run
    caller.run()
  File "/usr/lib/python2.7/dist-packages/salt/cli/caller.py", line 236, in run
    ret = self.call()
  File "/usr/lib/python2.7/dist-packages/salt/cli/caller.py", line 138, in call
    ret['return'] = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/salt/modules/state.py", line 523, in highstate
    whitelist=kwargs.get('whitelist')
  File "/usr/lib/python2.7/dist-packages/salt/state.py", line 2968, in call_highstate
    return self.state.call_high(high)
  File "/usr/lib/python2.7/dist-packages/salt/state.py", line 2067, in call_high
    ret = dict(list(disabled.items()) + list(self.call_chunks(chunks).items()))
  File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1623, in call_chunks
    running = self.call_chunk(low, running, chunks)
  File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1769, in call_chunk
    self._mod_init(low)
  File "/usr/lib/python2.7/dist-packages/salt/state.py", line 612, in _mod_init
    self.states['{0}.{1}'.format(low['state'], low['fun'])]  # pylint: disable=W0106
  File "/usr/lib/python2.7/dist-packages/salt/utils/lazy.py", line 90, in __getitem__
    raise KeyError(key)
KeyError: 'pip.installed'

Even though pip seems to be installed:

root@m1:~# python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pip
>>> import pip.req
>>>

What’s going on here? This is a MAJOR blocker for me b/c it’s breaking a bunch of states and making salt unusable.

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 25 (8 by maintainers)

Most upvoted comments

This is a regression in the state compiler for 2015.5.3 and it happens when you’re running states that depend on the existence of an external package. Instead of the state gracefully falling and telling you something like pip is unavailable, it stack traces. This is fixed on 2015.5.6 and 2015.8.0 with #27681 and #25928, respectively.

Can anyone here test those versions and confirm this is fixed?

Edit: The solutions mentioned above will correct the stacktrace seen in the initial report. The other issues reported here where pip is installed on all relevant machines, but pip.installed is still not working, is likely the same bug reported in #21845.

rallytime on Oct 15, 2015