Skip to content
This repository has been archived by the owner. It is now read-only.

yum_repository: allow enable/disable of repository #2384

Closed
hhsnow opened this issue Jun 7, 2016 · 21 comments

Comments

@hhsnow
Copy link

commented Jun 7, 2016

ISSUE TYPE
  • Feature Request
COMPONENT NAME

yum_repository

ANSIBLE VERSION
ansible 2.1.0.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides
CONFIGURATION
OS / ENVIRONMENT
SUMMARY

I am unable to use yum_repository to update enabled = 1 without providing additional configuration. For example, in Amazon Linux, they ship the epel repository with enabled = 0 by default. This would allow this repository to be enabled permanently. While I currently use the ini_file module, this seems like the right place.

STEPS TO REPRODUCE

Proposed item:

- name: yum | enable epel repository
  yum_repository:
    name: epel
    enabled: yes

Current Item:

- name: yum | enable epel repository
  yum_repository:
    name: epel
    description: "Extra Packages for Enterprise Linux 6 - $basearch"
    mirrorlist: "https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch"
    failovermethod: priority
    gpgkey: "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6"
    gpgcheck: yes
    enabled: yes
EXPECTED RESULTS

/etc/yum.repo.d/epel.repo should have the following line set:

[epel]
...
enabled=1
...
ACTUAL RESULTS
fatal: [example.com]: FAILED! => {"changed": false, "failed": true, "msg": "Parameter 'baseurl' or 'mirrorlist' is required."}
@resmo

This comment has been minimized.

Copy link
Member

commented Jun 18, 2016

/cc maintainer @jtyr

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2016

Current version of yum_repository module was mainly designed to create new repo files although it allows to override repo definition in existing files. For that you have to define complete repo definition including at least the name and one of the baseurl or mirrorlist.

I can imagine to extend the module with state: update which would allow to add/modify properties of existing repos:

- yum_repository:
    name: epel
    enabled: yes
    state: update

To remove an option from the repo definition, one could set the option to null value:

- yum_repository:
    name: epel
    failovermethod: null
    state: update

In both cases, there can be whole list of options to modify/remove.

Please let me know what do you think about it and I will try to implement it.

@hhsnow

This comment has been minimized.

Copy link
Author

commented Jun 24, 2016

That makes sense to me. Makes it easier to distinguish between a full change and a single element update. Do any other modules have an 'update' state?

@ansibot

This comment has been minimized.

Copy link

commented Aug 4, 2016

@jtyr, ping. This issue is still waiting on your response.
click here for bot help

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2016

I still need to find time to implement this. Hopefully I will have some time next week.

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2016

I think it would be better to use the init_file module to modify the single repo option:

- name: Enable EPEL repo
  ini_file:
    dest: /etc/yum.repos.d/epel.repo
    section: epel
    option: enabled
    value: 1

What do you think, @hhsnow? If this is acceptable solution, please close the issue.

@ansibot

This comment has been minimized.

Copy link

commented Aug 22, 2016

@jtyr, ping. This issue is still waiting on your response.
click here for bot help

@hhsnow

This comment has been minimized.

Copy link
Author

commented Aug 30, 2016

@jtyr I've been using the ini_file module already in playbooks, but I'd expect modifying anything related to yum repo files to be a feature of the yum_repository module. At the very least, I'd expect documentation in this module to point to the ini_file module.

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2016

As I mentioned earlier, yum_repository was created to be able to define new repos with their full definition. If you only want to change certain parameter without having to define all repo parameters, you better use the ini_file module. I will modify the yum_repository documentation to be more specific about this aspect.

@tcstang

This comment has been minimized.

Copy link

commented Aug 30, 2016

Although ini_file suffices, my organization, like @hhsnow were expecting similar functionality in yum_repository. We are actually opting to use the command module with yum-config-manager --enable/--disable as our current solution.

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2016

@tcstang I think the init_file is better way than using shell with the command you mentioned above. As I mentioned several times, yum_repository wasn't designed to be able to flip just certain pits of the YUM repo configuration. It was developed to be able to create complete definition of YUM repos.

I'm open to further discussion if you find another Ansible module of similar kind which is doing what you requesting. I just don't want to implement something what might create a precedence for other modules in the future.

@ansibot

This comment has been minimized.

Copy link

commented Oct 6, 2016

@jtyr, ping. This issue is still waiting on your response.
click here for bot help

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2016

I'm marking this issue as wontfix because I believe that using the init_file module is better solution than using the yum_repository module.

@ansibot ansibot closed this Oct 6, 2016

@jdranchman

This comment has been minimized.

Copy link

commented Oct 18, 2016

jytr
I'm rather new at ansible and so far any solution I've come up with using init_file (with shell or file or...) against an unknown set of existing repo config files has gotten real ugly real fast. I too would benefit from an enhancement of yum_repository to deal with existing repos (not just dealing with new configs). My current spin is to blow all of them away and remake what I want for a pulp config. Another viable option is to run a shell of yum-config-manager, disable everything (what ever is there) and then re-enable/add what I want - which kind of defeats the purpose of a simple ansible solution (and not using shell for everything). Would you reconsider extending your module to also manage existing repo configs?

@scottsb

This comment has been minimized.

Copy link

commented Dec 5, 2016

@jtyr, I would vote to reopen this issue. I understand that the original intent of the yum_repository module was to create brand new entries, but I don't see any reason why it needs to be restricted to that. The argument that it is possible to enable a repository using ini_file fails to persuade me because that argument could be used against the existence of yum_repository entirely, given that all management of yum repos can be done using ini_file. The benefit of yum_repository is syntactic sugar to make management more straightforward.

And, for what it's worth, expanding this functionality here is much cleaner than a separate syntactic sugar command as proposed in #2820.

@jtyr

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2016

There was a similar discussion in the issue #3530. I'm keen to review any PRs resulting into improving the functionality of the yum_repository module.

@scottsb

This comment has been minimized.

Copy link

commented Dec 5, 2016

As far as prior precedent, there are two that I can point to quickly:

macports: This module manages packages rather than repositories, but it is relevant for its additional states of active and inactive that can be set in addition to simply present and absent. If introduced here, it would address the immediate use case of enabling/disabling repositories, though I would prefer the more generalized original suggestion of update since it would allow configuration of other properties as well.

pkg5_publisher: This module appears to not require the repository URL for changing the enabled flag, but that may just be deficiency in the documentation.

@scottsb

This comment has been minimized.

Copy link

commented Dec 5, 2016

Thanks, @jtyr. I will follow the discussion there. Unlikely I'll have time to do a PR myself, but if I do, I will.

@sheldmandu

This comment has been minimized.

Copy link

commented Feb 5, 2017

Hi @jtyr I would also suggest that the functionality to enable a specific repo is needed and cannot be easily replicated with the ini_file module in all scenarios. A great example where I came across this is the remi repos for installing a specific version of php. Try install the rpm and look at the repo files. See https://blog.remirepo.net/post/2016/02/14/Install-PHP-7-on-CentOS-RHEL-Fedora There are multiple repos and some versions (7.0 and 7.1) live in their own .repo files. When you have a php version that you want to install in a variable to use the ini_file you have to do all kinds of string parsing and use conditional statements for your tasks, which is extremely cumbersome. I actually ended up installing yum-utils and just using yum-config-manager with changed_when: false as I don't want to have lots of unnecessary conditional logic in the playbooks.

@mdobrzyn

This comment has been minimized.

Copy link

commented Nov 17, 2017

Hi

To disable custom repo You can use yum-config-manager --disable reponame.
Example to remove repo that not contain channel in name.

  - name: Remove repository other than Spacewalk
    shell: repolist=`yum-config-manager | grep -e "repo:" | grep -v channel | awk '{ print $3 }' | xargs | sed 's/ /,/g'`; if [ $repolist ]; then yum-config-manager --disable $repolist; fi 
    tags:
      - repo
@hron84

This comment has been minimized.

Copy link

commented Nov 21, 2017

@jtyr hacking with the ini_file if a resource is available is not a good idea. Consider user or service module, if they would be only usable when the user/service is not defined yet, then they would be useless. Same for yum_repository, if it can be only used if the repo is not defined yet, it is useless. Please consider the same attitude across modules.

Also, as multiple users mentioned before, yum-config-manager can cover this functionality, on older systems you can parse yum configs with the core ConfigParser module.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.