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

prereq infinite recursion with pip #8212

Closed
djs52 opened this issue Nov 1, 2013 · 5 comments
Closed

prereq infinite recursion with pip #8212

djs52 opened this issue Nov 1, 2013 · 5 comments
Labels
Bug broken, incorrect, or confusing behavior Core relates to code central or existential to Salt P3 Priority 3 Regression The issue is a bug that breaks functionality known to work in previous releases. severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around stale
Milestone

Comments

@djs52
Copy link

djs52 commented Nov 1, 2013

I've been using prereq to stop a service before upgrading a package installed with pip. This worked fine in 0.16.3, but with 0.17.1 I get infinite recursion of

  File "/usr/lib/pymodules/python2.7/salt/state.py", line 1504, in call_chunk
    running = self.call_chunk(low, running, chunks)

Small test states:

example:
  pip:
    - installed
  service:
    - require:
      - pip: example
    - running
    - enable: true

stop-before-upgrade:
  service:
    - name: example
    - dead
    - prereq:
      - pip: example

Note that in the output I also see

[ERROR   ] State pip.installed found in sls test is unavailable

even though I've got python-pip installed. I don't know if this is related. It may also be related to #8210

@basepi
Copy link
Contributor

basepi commented Nov 1, 2013

I'm not sure it's related to #8210, because that one we expect infinite recursion, he just wants better error reporting or earlier detection. This one is more troubling, especially because it seems to be a regression. We'll figure it out. Thanks for the report!

@basepi basepi modified the milestones: Approved, Outstanding Bugs Apr 21, 2014
@cachedout
Copy link
Contributor

I tested this against develop with a minor modification, just to align with a service I happened to have running:

example:
  pip:
    - installed
  service:
    - name: slapd
    - require:
      - pip: example
    - running
    - enable: true

stop-before-upgrade:
  service:
    - name: slapd
    - dead
    - prereq:
      - pip: example
root@silver:/srv/salt# salt-call --local state.sls pip
[INFO    ] Loading fresh modules for state activity
[INFO    ] Running state [example] at time 15:08:46.822960
[INFO    ] Executing command '/usr/bin/pip2 freeze' in directory '/root'
[INFO    ] Running state [slapd] at time 15:08:47.008915
[INFO    ] Executing state service.dead for slapd
[INFO    ] Executing command 'runlevel /run/utmp' in directory '/root'
[INFO    ] Executing command 'service slapd status' in directory '/root'
[INFO    ] Executing command 'service slapd stop' in directory '/root'
[INFO    ] {'slapd': True}
[INFO    ] Completed state [slapd] at time 15:08:47.126216
[INFO    ] Running state [example] at time 15:08:47.126924
[INFO    ] Executing state pip.installed for example
[INFO    ] Executing command '/usr/bin/pip2 freeze' in directory '/root'
[INFO    ] Executing command "/usr/bin/pip2 install 'example'" in directory '/root'
[INFO    ] Executing command '/usr/bin/pip2 freeze' in directory '/root'
[INFO    ] {'example==0.1.0': 'Installed'}
[INFO    ] Completed state [example] at time 15:08:48.576719
[INFO    ] Running state [slapd] at time 15:08:48.577049
[INFO    ] Executing state service.running for slapd
[INFO    ] Executing command 'service slapd status' in directory '/root'
[ERROR   ] Command 'service slapd status' failed with return code: 3
[ERROR   ] output:  * slapd is not running
[INFO    ] Executing command 'service slapd start' in directory '/root'
[INFO    ] {'slapd': True}
[INFO    ] Completed state [slapd] at time 15:08:48.667788
local:
----------
          ID: stop-before-upgrade
    Function: service.dead
        Name: slapd
      Result: True
     Comment: Service slapd was killed
     Started: 15:08:47.008915
     Duration: 117 ms
     Changes:   
              ----------
              slapd:
                  True
----------
          ID: example
    Function: pip.installed
      Result: True
     Comment: Package was successfully installed
     Started: 15:08:47.126924
     Duration: 449 ms
     Changes:   
              ----------
              example==0.1.0:
                  Installed
----------
          ID: example
    Function: service.running
        Name: slapd
      Result: True
     Comment: Service slapd is already enabled, and is running
     Started: 15:08:48.577049
     Duration: 90 ms
     Changes:   
              ----------
              slapd:
                  True

Summary
------------
Succeeded: 3 (changed=3)
Failed:    0
------------
Total states run:     3

@djs52 This is against the current develop. I suspect this has been fixed since 0.17. Can you confirm? We can probably close this issue if things are working now.

@djs52
Copy link
Author

djs52 commented May 21, 2014

I've just tried this on a few servers. I still see infinite recursion, but only on those which also show

[ERROR   ] State pip.installed found in sls test is unavailable

in the output.

On Ubuntu 12.04, installing python-pip fixed this as expected. On Ubuntu 10.04, it didn't. So I guess there are two bugs here: the error handling when pip is not found should be better; and there is a problem loading pip on Ubuntu 10.04.

@basepi
Copy link
Contributor

basepi commented May 21, 2014

The 10.04 issue sounds like it might be a outdated-pip issue, though I haven't done any testing.

So I think our path is two-fold -- we need to see if we can fix the infinite recursion when pip isn't installed, and while we're at we should check into pip incompatibility in Ubuntu 10.04.

@rallytime rallytime added severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around Core relates to code central or existential to Salt P3 Priority 3 and removed Low Severity labels Aug 25, 2015
@stale
Copy link

stale bot commented Dec 22, 2017

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 Dec 22, 2017
@stale stale bot closed this as completed Dec 29, 2017
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 Core relates to code central or existential to Salt P3 Priority 3 Regression The issue is a bug that breaks functionality known to work in previous releases. severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around stale
Projects
None yet
Development

No branches or pull requests

4 participants