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.highstate error with require_in: sls: #47182

Open
MartinEmrich opened this Issue Apr 19, 2018 · 15 comments

Comments

Projects
None yet
4 participants
@MartinEmrich

MartinEmrich commented Apr 19, 2018

Description of Issue/Question

state.highstate test=true returns with

    Passed invalid arguments to state.highstate: list indices must be integers, not unicode

(followed by the complete state.highstate docs).

state.show_top works fine, and returns the expected result.

running state.sls with each individual state works, too.
But state.highstate does not.

I found that when I removed the "require_in" block of something like

include:
  - slsfile1
  - slsfile2

some-state:
  test.nop:
    - require:
      - sls: slsfile1
    - require_in:
      - sls: slsfile2

the error no longer appears. The same states worked fine in Salt 2017.x.x

The closest Issue I found is #22852, but that's supposed to be fixed. In either case, an error message pointing to the exact location would be nice (I had to "bisect" the state tree down to the exact location).

In the minion log file (level: trace), I found this Traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/salt/minion.py", line 1600, in _thread_return
    return_data = minion_instance.executors[fname](opts, data, func, args, kwargs)
  File "/usr/lib/python2.7/site-packages/salt/executors/direct_call.py", line 12, in execute
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/salt/modules/state.py", line 1055, in highstate
    orchestration_jid=orchestration_jid)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 3881, in call_highstate
    return self.state.call_high(high, orchestration_jid)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 2693, in call_high
    high, req_in_errors = self.requisite_in(high)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 1574, in requisite_in
    hinges = find_sls_ids(pname, high)
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 246, in find_sls_ids
    if item['__sls__'] == sls:
TypeError: list indices must be integers, not unicode

Setup

Steps to Reproduce Issue

see above

Versions Report

Master:
Salt Version:
Salt: 2018.3.0

Dependency Versions:
cffi: Not Installed
cherrypy: unknown
dateutil: Not Installed
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.8.1
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
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.14 (default, Jan 31 2018, 02:12:13)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 14.5.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.0.5

System Versions:
dist: centos 6.9 Final
locale: UTF-8
machine: x86_64
release: 2.6.32-696.20.1.el6.x86_64
system: Linux
version: CentOS 6.9 Final

Minion:
Salt Version:
Salt: 2018.3.0

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.21.1
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.8
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.6.el7.x86_64
system: Linux
version: CentOS Linux 7.4.1708 Core

Thanks,

Martin

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Apr 20, 2018

I'm having a hard time replicating this. Here is my test case:

/srv/salt/top.sls:

base:
  '*':
    - test

/srv/salt/test.sls

include:
  - slsfile1
  - slsfile2

some-state:
  test.nop:
    - require:
      - sls: slsfile1
    - require_in:
      - sls: slsfile2

/srv/salt/slsfile1:

echo test:
  cmd.run

/srv/salt/slsfile2:

echo 2:
  cmd.run
[root@654f87aca97d /]# salt '*' state.highstate
654f87aca97d:
----------
          ID: echo test
    Function: cmd.run
      Result: True
     Comment: Command "echo test" run
     Started: 14:21:04.733682
    Duration: 137.495 ms
     Changes:   
              ----------
              pid:
                  952
              retcode:
                  0
              stderr:
              stdout:
                  test
----------
          ID: some-state
    Function: test.nop
      Result: True
     Comment: Success!
     Started: 14:21:04.872363
    Duration: 0.331 ms
     Changes:   
----------
          ID: echo 2
    Function: cmd.run
      Result: True
     Comment: Command "echo 2" run
     Started: 14:21:04.872827
    Duration: 171.403 ms
     Changes:   
              ----------
              pid:
                  954
              retcode:
                  0
              stderr:
              stdout:
                  2

Summary for 654f87aca97d
------------
Succeeded: 3 (changed=2)
Failed:    0
------------
Total states run:     3
Total run time: 309.229 ms
[root@654f87aca97d /]# salt --version
salt 2018.3.0 (Oxygen)

Can you share your slsfile1 and slsfile2?

@Ch3LL Ch3LL added this to the Blocked milestone Apr 20, 2018

@MartinEmrich

This comment has been minimized.

MartinEmrich commented Apr 20, 2018

Indeed, the "slsfile1" and "slsfile2" again include and depend on other state files, the whole tree is quite deep, and sadly contains loads of stuff I am not allowed to disclose here :(

My colleague "fixed" it in the meantime by replacing the "require_in: sls" with "require:" in the deeper sls files.

Might there be a "nesting depth" limitation to require_in?

@MartinEmrich

This comment has been minimized.

MartinEmrich commented Apr 23, 2018

Hi!

Out of curiosity, we reverted to the failing tree today.

We discovered that in another state, a previous include was excluded. After removing the exclude, it works, too:

# top.sls
base:
  - stateA
  - stateB
# stateA/init.sls
include:
  - stateA.newer
# stateA/newer.sls
exclude:
  - sls: stateA

somestuff:
  cmd.run:
     - name: echo This supersedes the stuff previously done in stateA
# stateB.sls (as above)
include:
  - slsfile1
  - slsfile2

some-state:
  test.nop:
    - require:
      - sls: slsfile1
    - require_in:
      - sls: slsfile2

Excluding the SLS stateA from stateA.newer that included stateA.newer in the first place seems wrong, and indeed, after removing the exclude: there, it works.
But applying stateA alone works, as does applying stateB alone. Both together worked in 2017.7 too.

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Apr 23, 2018

using hte test case you provided aboe i'm replicating it in 2017.7.4 but your stating it was working?

@MartinEmrich

This comment has been minimized.

MartinEmrich commented Apr 24, 2018

At least no one was complaining... If you can replicate it, it is safe to assume that noone tried it before our upgrade to 2018.3.

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Apr 24, 2018

ping @saltstack/team-core any ideas why this is occuring?

@terminalmage

This comment has been minimized.

Member

terminalmage commented May 16, 2018

This doesn't make sense to me... @MartinEmrich, your second example references two undefined SLS files in stateB.sls.

@MartinEmrich

This comment has been minimized.

MartinEmrich commented May 16, 2018

@terminalmage Just take something, the content does not matter....

@terminalmage

This comment has been minimized.

Member

terminalmage commented May 16, 2018

I'm sorry, I don't understand your reply. Are you saying to create slsfile1 and slsfile2 and put any states into them?

@terminalmage

This comment has been minimized.

Member

terminalmage commented May 16, 2018

Yeah that looks like what you meant. I've gotten it to reproduce in 2017.7 as well as 2018.3. I have a fix already written, and attempting to write a unit test for this now.

@MartinEmrich

This comment has been minimized.

MartinEmrich commented May 16, 2018

Yes indeed, just two arbitrary state files, where stateB works as a kind of "barrier" between the two.
Good to hear that you found the issue :)

@terminalmage

This comment has been minimized.

Member

terminalmage commented May 16, 2018

This is fixed in #47682. @Ch3LL I set up a docker container to reproduce, can you sanity check it? Just run the following from the root of a git checkout of the head of 2017.7 and 2018.3:

docker run --rm -it -v $PWD:/testing terminalmage/issues:47182 salt-call state.apply

This should reproduce the error referenced in the OP (though on 2017.7 it will mention str instead of unicode).

However, when checking out my PR locally and running it against that branch, the state.apply should run as expected.

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented May 17, 2018

yep it works :)

@jeffdyke

This comment has been minimized.

jeffdyke commented Aug 21, 2018

I added a comment to the PR as well but for completeness..., this did not make it into 2018.3.2 and i'm hitting the same issue. I can patch all my minions, but that seems silly.

Sorry, and thank you!

@jeffdyke

This comment has been minimized.

jeffdyke commented Aug 21, 2018

Solved in PR comments. thanks to @gtmanfred

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment