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

pkgrepo.managed doesn't handle moving from mirrorlist to baseurl on Yum based systems #9121

Closed
tlk2126 opened this issue Dec 9, 2013 · 4 comments · Fixed by #9133
Closed
Labels
Bug broken, incorrect, or confusing behavior

Comments

@tlk2126
Copy link
Contributor

tlk2126 commented Dec 9, 2013

If you switch from a mirrorlist configured pkgrepo:

repo-epel:
    pkgrepo:
        - managed
        - name: epel
        ...
        - mirrorlist: https://mirrors.fedoraproject.org/metalink?repo=epel-source-6&arch=$basearch

to

repo-epel:
    pkgrepo:
        - managed
        - name: epel
        ...
        - baseurl: http://mirror.cc.columbia.edu/pub/linux/epel/6/$basearch/

and run a state.highstate, the proper baseurl line is added, but the mirrorlist line is left in the configuration, which means yum will still try to use that.

@basepi
Copy link
Contributor

basepi commented Dec 9, 2013

Thanks for catching this! We'll get it fixed.

@basepi
Copy link
Contributor

basepi commented Dec 9, 2013

What version of salt are you running?

@terminalmage
Copy link
Contributor

I'm fairly certain this will affect all versions, since all the args in the state are passed through to the function that writes the repo config file. I'll add some logic to include a check on yum-based systems for this sort of change.

@terminalmage
Copy link
Contributor

@tlk2126 I've submitted a fix for this in #9133. Due to the way changes are returned from pkgrepo states currently, Salt doesn't report that it has deleted the corresponding key when it shows the changes in the highstate output. Doing this will require more substantial changes to the apt and yum pkgrepo functions as well as the pkgrepo state, so this will have to be done another time. But for now, the behavior will be functionally accurate, which is more important IMO than for the reporting of changes to be 100% accurate. We'll still get to that, it just might take a few weeks. :)

Thanks again for reporting this!

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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants