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

cache of available pkgs not cleared when repos are changed #11001

Closed
dara0418 opened this issue Mar 6, 2014 · 3 comments · Fixed by #11025
Closed

cache of available pkgs not cleared when repos are changed #11001

dara0418 opened this issue Mar 6, 2014 · 3 comments · Fixed by #11025
Labels
Bug broken, incorrect, or confusing behavior Pending-Discussion The issue or pull request needs more discussion before it can be closed or merged severity-low 4th level, cosemtic problems, work around exists

Comments

@dara0418
Copy link

dara0418 commented Mar 6, 2014

Hi,

This is possible a bug of release 2014.1. Refers to commit 56f01ea

The pkg.installed can't find the package properly sometimes. This is due to the salt['avail'] cache dict is not reloaded in some situations. In my test case, I have a private yum repository managed. I installed epel repository rpm package from my private repository and managed a new postgresql-9.2 repository. And then I'm trying to install something from the epel and postgresql9.2 repositories, and it failed. Here's my script and the error messages:

# This is my private repository.
private-repo:
  pkgrepo.managed:
    - humanname: Private repository
    - baseurl: http://192.168.129.242/megaphone/centos/$releasever/$basearch
    - gpgcheck: 0
    - enabled: 1

# I was trying to install epel repository from my private repository.
epel-repo:
  pkg.installed:
    - name: epel-release
    - require:
      - pkgrepo: private-repo

# Then I installed something.
syslog-ng:
  pkg.installed:
    - refresh: True
    - require:
      - pkg: epel-repo

# Then I added another postgresql9.2 repository.
postgresql92-repo:
  pkgrepo.managed:
    - humanname: PostgreSQL 9.2 $releasever - $basearch
    - baseurl: http://yum.postgresql.org/9.2/redhat/rhel-$releasever-$basearch
    - gpgcheck: 0
    - enabled: 1

# Now I want to install postgresql92 server.
postgresql92-server:
  pkg.installed:
    - refresh: True
    - require:
      - pkgrepo: postgresql92-repo

There are two failure states:

...

      ID: syslog-ng
Function: pkg.installed
  Result: False
 Comment: Package 'syslog-ng' not found (possible matches: syslog-ng)
 Changes:

...

      ID: postgresql92-server
Function: pkg.installed
  Result: False
 Comment: Package 'postgresql92-server' not found (possible matches: postgresql92-server)
 Changes:

If I run the same script for another time, the failed states will work.

After dive into the code, I found you recently added a global cache dict for available packages (__salt__['avail']), and it was not reloaded correctly in this situation (used the old cache). Currently I just removed the cache dict as a quick work around (removed line 391-393 from yumpkg.py). Please review this issue, thanks a lot.

@basepi
Copy link
Contributor

basepi commented Mar 6, 2014

Thanks for the report! Are you on 2014.1.0 or just the 2014.1 branch? (salt --versions-report would be great)

@terminalmage I think you're most familiar with this code. Sounds like @dara0418 has a workaround, but can you look into that caching issue?

@terminalmage
Copy link
Contributor

This is fixed in #11025. I've also changed the name of this issue to reflect the actual issue, as the initial name was not descriptive at all.

@dara0418
Copy link
Author

dara0418 commented Mar 7, 2014

@basepi @terminalmage Thanks for the updates. It should be on 2014.1.0.

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 Pending-Discussion The issue or pull request needs more discussion before it can be closed or merged severity-low 4th level, cosemtic problems, work around exists
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants