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
dnf: support config-manager plugin for repository management #46963
Comments
|
Hi @nullr0ute, thank you for submitting this issue! |
|
Files identified in the description: If these files are inaccurate, please update the |
|
@nullr0ute: in order for the community to handle your issue effectively, we need a bit more information. Here are the items we could not find in your description:
Please set the description of this issue with this template: |
|
@nullr0ute do you think should be an extension of the I'm leaning towards net new module but I'm open to discussion on the topic. |
|
@maxamillion if I may make a suggestion, a new module seems to make more sense here because when adding a repo one may not necessarily be installing a package... it seems it would be more work to integrate it into the dnf module than to make an entirely new one. If it would be helpful, I could take this on to learn a bit about the ansible codebase |
|
@NerdsvilleCEO that would be amazing, I would greatly appreciate it! I'm happy to help along the way as well if you need anything. I'm always in |
|
Having this would be greatly appreciated. I just ran into a case where I could not use the yum_repository module to set up repos for dnf; The setting for using deltaRPM differs between I am happy to test once there is a Things I can effortlessly test.
but I'm happy to test more if needed. |
|
Any development on this? |
|
Files identified in the description: If these files are incorrect, please update the |
|
There hasn't been, I'll take a look tomorrow, thank you for pinging @MaartenMol |
|
Gentle nudge... |
|
Any update on this? I'm trying to automate the install of |
I had the same use case. Ended up wiht using Shell commands as workaround for the time being. |
|
Hey everyone, just checking in. This hasn't been forgotten but unfortunately it's not something I've had the cycles to get around to implementing. If anyone would like to submit a patch including the feature enhancement I would gladly review it. This is still on my TODO list, but unfortunately other things have been taking priority. |
|
Only 1 specific case but in case it helps anyone else, my current workaround for enabling a repo (powertools in this case, needed for centos8 only) was: |
|
Perhaps an easier workaround? |
|
I've been meaning to get to this for so long but haven't made much progress, if anyone is interested in this task feel free to take it |
|
We have moved on from CentOS to Ubuntu due to the latest developments. |
When it comes to |
|
Yes you're right - the "add repo" and "enable repo" cases are different. |
|
I adapted your lineinfile task to a playbook of mine, btw. Thanks, @sjpb ! |
|
Does https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_repository_module.html work for at least some of the command like "add/enable"? |
|
Bumping this issue. Imo, this is a pretty essential feature and should be added. |
|
Bump. I'm currently using a shell command as a workaround but it would be a lovely addition to Ansible! |
|
@maxamillion |
|
@telometto maximillion moved on to a diff position and is not part of the core team anymore. The bot responds to all new modules/plugins by redirecting people to collections, since we split them out we are trying to keep those in core to a minimum. But if you disagree and want to make your case for an exception, please feel free to add this to the core meeting irc agenda so the team can discuss and decide on this case. https://github.com/ansible/community/issues?q=is:open+label:meeting_agenda+label:core |
|
The repo configuration files are in "INI" format, so I think it's better to use the What about this example ? - name: "Enable AlmaLinux PowerTools repo"
community.general.ini_file:
path: /etc/yum.repos.d/almalinux-powertools.repo
section: powertools
option: enabled
value: 1
create: no
when: ansible_distribution == "AlmaLinux"It's clean, simple and really useful to specify the section name because some configuration file can define a lot of repos and you don't want to enable all. |
|
Good catch, thanks. |
|
I too would appreciate existence of something like that. Would help me improve automation of ffmpeg in Rocky 9. I could imagine something like: - name: "Enable CRB repo"
ansible.builtin.dnf_config_manager:
name: crb
enabled: yes |
|
The Basically closing this per #46963 (comment) If you have further questions please stop by IRC or the mailing list:
|
|
I think "closed as completed" is a bit misleading! "Won't fix" would be clearer for the next person who finds this (and to be clear, I understand/accept the position that new modules are going into collections, not core). |
SUMMARY
The dnf config-manager plugin is the means of managing the actual rpm repositories available to dnf. In Fedora it's use for managing installed but not enabled by default repositories such as updates-testing and some media codecs. In RHEL these repositories are used extensively for extras/optional and other such repos.
dnf config-manager supports the following options that would be useful to manage using ansible:
https://dnf-plugins-core.readthedocs.io/en/latest/config_manager.html
ISSUE TYPE
COMPONENT NAME
dnf module
ADDITIONAL INFORMATION
dnf provides a lot of repos and while the ansible dnf module enables you to manage installing/upgrading/removing packages and you can temporarily enable a repo as part of that process there is no means to manage the repositories themselves, so for example if you enable a repository to install a particular package but forget to enable that repository when applying updates you may miss critical updates to the packages that are installed by ansible. By managing being able to the repository you can enable the repository at the beginning of a task (eg fedora-cisco-openh264), install the package using the default means (ie not enabling the repo in the install component), and updates automatically get applied as part of an upgrade task without having to track what special usecases enabled repos as part of an install task.
The text was updated successfully, but these errors were encountered: