Fedora 22 defaults to dnf for package management

[jordane]

Fedora 22 is switching to a new package manager, dnf. They provide a legacy package (installed by default) which will provide an executable named yum, but there are a number of differences.

As far as I can tell, most of the differences won't affect the yum provider, but I wanted to open an issue on this to increase awareness. I'm planning on writing a DNF provider in the near future, but if someone else gets to it first that is fine with me.

[ramereth]

I just tried this on an F22 VM and got the following (using chef-12.2.1)

================================================================================    
Error executing action `upgrade` on resource 'yum_package[bash]'           
================================================================================           

Mixlib::ShellOut::ShellCommandFailed           
------------------------------------           
Expected process to exit with [0], but received '1'           
---- Begin output of /usr/bin/python /opt/chef/embedded/apps/chef/lib/chef/provider/package/yum-dump.py --options --installed-provides --yum-lock-timeout 30 ----           
STDOUT:            
STDERR: Traceback (most recent call last):           
  File "/opt/chef/embedded/apps/chef/lib/chef/provider/package/yum-dump.py", line 36, in <module>           
    import yum           
ImportError: No module named yum           
---- End output of /usr/bin/python /opt/chef/embedded/apps/chef/lib/chef/provider/package/yum-dump.py --options --installed-provides --yum-lock-timeout 30 ----       
Ran /usr/bin/python /opt/chef/embedded/apps/chef/lib/chef/provider/package/yum-dump.py --options --installed-provides --yum-lock-timeout 30 returned 1        

You can install a yum package which seems to translate it to dnf commands which seems to mostly work ... until I ran into this problem randomly:

================================================================================    
Error executing action `upgrade` on resource 'yum_package[ethtool]'           
================================================================================           

Chef::Exceptions::Exec           
----------------------           
yum -d0 -e0 -y install ethtool-3.18-1.fc22 returned 1:           
STDOUT:            
STDERR: Yum command has been deprecated, use dnf instead.           
See 'man dnf' and 'man yum2dnf' for more information.           
To transfer transaction metadata from yum to DNF, run 'dnf migrate'Redirecting to '/usr/bin/dnf -d0 -e0 -y install ethtool-3.18-1.fc22'           

Anyways, seems like we really need to have this provider at some point. Hopefully this is helpful.

[juliandunn]

@jordane We definitely would welcome the contribution.

[jtimberman]

Fedora 22 was released yesterday. According to our supported platforms list, we have Fedora as a Tier 2 platform for "non-EOL releases" which at this time is Fedora 20 through 22. It would be dope if we supported DNF as a package provider.

[thommay]

Properly supporting hawkey (the library under DNF) would allow us to bin the grotty yum-python script we carry around. My quick investigation suggests we should be able to use hawkey if it's available on everything from FC18, and probably RHEL 6/7 too.

[jordane]

@thommay hawkey isn't readily available on RHEL/Centos 6, and isn't installed by default on 7. Properly supporting hawkey is definitely the right way to go, but I don't know if the old python script should be binned until Chef no longer supports RHEL/Centos 6.

[spheromak]

👍 on hawkey and ditching yum-dump.py

[jtimberman]

Fwiw, to work around the error @ramereth posted,

Mixlib::ShellOut::ShellCommandFailed           
------------------------------------           
Expected process to exit with [0], but received '1'           
---- Begin output of /usr/bin/python /opt/chef/embedded/apps/chef/lib/chef/provider/package/yum-dump.py --options --installed-provides --yum-lock-timeout 30 ----           
STDOUT:            
STDERR: Traceback (most recent call last):           
  File "/opt/chef/embedded/apps/chef/lib/chef/provider/package/yum-dump.py", line 36, in <module>           
    import yum           
ImportError: No module named yum           

Install the yum package first.

package 'yum'

Should do the trick.

[jtimberman]

Welp, I thought that would do the trick, and it worked on a few packages, but not all of them in my test recipes (build-essential, and a custom one).

[joemiller]

@jtimberman We have noticed the same thing. And we're working on a dnf_package provider at the moment.

FWIW, and to help others who are going down the chef + dnf path: we have found a couple issues with the current yum_package provider and dnf's yum compatibility layer:

1. yum_package; source '/path/to/pkg.rpm' installs will fail since dnf does not provide a yum localinstall command. Instead dnf uses the same dnf install command for both local and remote installs.
2. Packages with a non-zero epoch confuse yum-dump/chef. For example, on fedora-22 the tomcat RPM is named like "tomcat-1:7.3.24". The yum provider (based on the output from yum-dump.py I presume) will try to execute yum install tomcat-7.3.24. Dnf is not as forgiving as yum and will fail with a package not found error. The correct usage would be to include the epoch, eg: {yum|dnf} install tomcat-1:7.3.24

[jtimberman]

@joemiller I see the exact same thing with the Epoch. Thanks for starting on a dnf package provider - is that one for core chef, or as a cookbook? It should definitely be in core chef imo, with the provider lookup stuff that @lamont-granquist added for systemd detection.

[joemiller]

We're working on it as a cook for now but I'm sure we'll contribute it back
to core chef when we're happy with the quality.

On Mon, Jun 15, 2015 at 8:19 AM, Joshua Timberman notifications@github.com
wrote:

@joemiller https://github.com/joemiller I see the exact same thing with
the Epoch. Thanks for starting on a dnf package provider - is that one for
core chef, or as a cookbook? It should definitely be in core chef imo, with
the provider lookup stuff that @lamont-granquist
https://github.com/lamont-granquist added for systemd detection.

—
Reply to this email directly or view it on GitHub
#3201 (comment).

[fujin]

Yer plan was to build up DNF support in this cookbook, get some confidence around it, then move the HWRP into Core.

[RavenB]

@jtimberman a not advised way to work around at the moment (we had to for some fedora machines) is to : dnf install yum (this actually installs yum-deprecated), rename yum to yum-dnf or whatever you wish, symbolic link yum to yum-deprecated (ok until dnf gets updated again, as i said a temp solution ). This will currently make most chef recipes work. as the yum-deprecated is supposed to be the copy of the real old yum.
Helped us with allot of broken recipes.
However anyone and @fujin having a dnf cookbook i am so willing to test ! :)
Anyone with a better workaround let me know too.
sorry if this is redundant or not the best workaround.

[lamont-granquist]

It should be reasonably straightforwards to patch the yum provider to use /usr/bin/yum-deprecated over /usr/bin/yum if it finds it on the system.

[et304383]

Any further status updates on package supporting dnf under Fedora 22? We're unable to use Fedora 22 at work as we're reliant on Chef to setup machines for development.

[lamont-granquist]

I merged the yum-deprecated workaround to the yum provider in #3774

[gawbul]

Anyone working on dnf support currently? I've got a couple of weeks spare time, so would be happy to help out with this if needed?

[joemiller]

We have a working dnf provider that we've been using in prod with fedora-22 for about two months now. It's implemented as a lib cook right now but could be easily integrated into chef core. At this point I think it's stable enough that it's worth opening up for wider feedback. There could be a debate about how we implemented the provider since it is different (but much simpler, in our opinion) than the existing yum provider. I'll confer w/ my colleagues about opening it up and then hopefully we can make the repo public soon-ish. I'm currently at the chef summit if anyone wants to find myself or jesse (@spheromak) to chat more about it too.

[ramereth]

@joemiller me @jordane are certainly interested in seeing that. We're both here too.

[joemiller]

https://github.com/pantheon-cookbooks/dnf

Some TL;DR on the above ^^ cook:

• We have been using this with fedora-22 nodes in production for a couple months now. The move from yum to dnf in fedora-22 was the compelling event for writing this.
• There is a dnf-query.py helper script. This is used to query the yum/dnf repo metadata for available versions. It is executed at least once per dnf_package resource. Ideally this will be replaced with a native ruby interface to dnf one day.
• No caching of metadata inside the chef runtime like the yum provider performs. We expected a bigger performance hit from this than we saw. We have not done benchmarks on the differences though.
• We did not implement the various 'whatprovides' functions of yum, including version specs like package "foo >= 3.2.1.fc16. Although there is some initial support for this in dnf-query.py and it does not look complicated, if someone finds this an important feature.
• arch support is not well tested and may not work. (We are basically 64bit only shop and this hasn't been an issue for us)
• There is currently a conditional wrapped around the classes in the cookbook so that when/if chef core supports a dnf_package resource that these will be silently ignored/not-loaded.

We opened up the cook so others could see what approach we took and try it out if they're currently blocked on dnf support. We intend to submit a PR with the same code to chef core for further discussions about dnf support within chef. (hopefully within a week or two)

[juliandunn]

@joemiller 🚀 🍰 thanks for this! I will check it out. I'm blocked on not having a dnf provider.

[gawbul]

👍 😄

[SoCalLongboard]

I'm on Fedora 23 and encountered the same issue. For the near term, I just installed yum (sudo dnf install yum) which didn't overwrite /usr/bin/yum with a true yum executable but installations via chef which employ yum seem to be working without warning/error for me.