Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State with mislabel module in onfail_any causes maximum recursion depth exceeded in cmp #51601

Open
kajigga opened this issue Feb 12, 2019 · 4 comments
Labels
Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Milestone

Comments

@kajigga
Copy link

kajigga commented Feb 12, 2019

Description of Issue/Question

When an sls file included an onfail_any requisite but this requisite has a mis-labeled module type, a maximum recursion depth exceeded in cmp error is displayed without any messages about a missing requisite.

Setup

(Please provide relevant configs and/or SLS files (Be sure to remove sensitive info).)

# /srv/salt/causes_recursion.sls
print_info:
  test.configurable_test_state:
    - name: foo
    - changes: True
    - result: True
 
print_info_2:
  test.configurable_test_state:
    - name: foo
    - changes: True
    - result: True
 
# this works referencing the module names
print_info_3:
  test.configurable_test_state:
    - name: foo
    - changes: True
    - result: True
    - onfail_any:
      - test: print_info
      - test: print_info_2
 
# this works (no module names)
print_info_4:
  test.configurable_test_state:
    - name: foo
    - changes: True
    - result: True
    - onfail_any:
      - print_info
      - print_info_2
 
 
# this triggers the recursion because the module for print_info is `salt` when
# it should be `test`
print_info_5:
  test.configurable_test_state:
    - name: foo
    - changes: True
    - result: True
    - onfail_any:
      - salt: print_info
      - test: print_info_2

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)

salt-call state.sls causes_recursion -ldebug

The output will be something like this.

[ERROR   ] An un-handled exception was caught by salt's global exception handler:
RuntimeError: maximum recursion depth exceeded in cmp
Traceback (most recent call last):
  File "/bin/salt-call", line 11, in <module>
    salt_call()
  File "/usr/lib/python2.7/site-packages/salt/scripts.py", line 410, in salt_call
    client.run()
  File "/usr/lib/python2.7/site-packages/salt/cli/call.py", line 57, in run
    caller.run()
  File "/usr/lib/python2.7/site-packages/salt/cli/caller.py", line 134, in run
    ret = self.call()
  File "/usr/lib/python2.7/site-packages/salt/cli/caller.py", line 212, in call
    ret['return'] = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/salt/modules/state.py", line 1327, in sls
    ret = st_.state.call_high(high_, orchestration_jid)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 2764, in call_high
    ret = self.call_chunks(chunks)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 2129, in call_chunks
    running = self.call_chunk(low, running, chunks)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 2563, in call_chunk
    running = self.call_chunk(low, running, chunks)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 2563, in call_chunk
    running = self.call_chunk(low, running, chunks)

    ...

  File "/usr/lib/python2.7/site-packages/salt/loader.py", line 1155, in __getitem__
    func = super(LazyLoader, self).__getitem__(item)
  File "/usr/lib/python2.7/site-packages/salt/utils/lazy.py", line 97, in __getitem__
    if key not in self._dict and not self.loaded:
RuntimeError: maximum recursion depth exceeded in cmp

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
           Salt: 2018.3.3

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.28.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Aug  4 2017, 00:39:18)
   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.4.1708 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-693.11.1.el7.x86_64
         system: Linux
        version: CentOS Linux 7.4.1708 Core
@kajigga kajigga changed the title State with typo in onfail_any causes maximum recursion depth exceeded in cmp State with mislabel module in onfail_any causes maximum recursion depth exceeded in cmp Feb 12, 2019
@Ch3LL
Copy link
Contributor

Ch3LL commented Feb 13, 2019

looks like i'm also able to replicate this also on the head of 2018.3 an 2019.2. we could probably do a better job at catching this misconfiguration. thanks :)

@Ch3LL Ch3LL added Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around P4 Priority 4 triage labels Feb 13, 2019
@Ch3LL Ch3LL added this to the Approved milestone Feb 13, 2019
@stale
Copy link

stale bot commented Jan 9, 2020

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.

@stale stale bot added the stale label Jan 9, 2020
@max-arnold
Copy link
Contributor

#55542 #55777

@stale
Copy link

stale bot commented Jan 9, 2020

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

@stale stale bot removed the stale label Jan 9, 2020
@sagetherage sagetherage removed the P4 Priority 4 label Jun 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Projects
None yet
Development

No branches or pull requests

4 participants