Seeing version incompatibilities on installation, Ubuntu 14.04

[migurski]

On Ubuntu 14.04, I started seeing this error earlier today:

ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: chef requires mixlib-shellout (~> 1.4); ohai requires mixlib-shellout (< 3.0, >= 2.0.0.rc.0)

Shouldn’t that be trivial to resolve, or am I misunderstanding the meaning of ~>?

Here is the context: run.sh. This worked fine earlier in the morning, now consistently fails with the error above.

[jaym]

~> 1.4 will match up to 2 but not including
@stevendanna and @sersut were looking into this earlier today, not sure how far they got.
I think the work around for now would be to execute a gem install ohai --version 7.4.0

@opscode/client-engineers would it be possible to yank the gem and bump ohai to 8?

[migurski]

Thanks, I’ve confirmed that this works:

gem install ohai -v 7.4.0 --no-rdoc --no-ri
gem install chef --no-rdoc --no-ri

[caboteria]

This borks the installation of any gem that depends on chef, e.g., minitest-chef-handler, but unfortunately the error message in that case isn't as helpful as the one migurski got:

$ sudo gem install minitest-chef-handler
ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: ohai requires mixlib-shellout (< 3.0, >= 2.0.0.rc.0)

It's also a problem on every platform, not just Ubuntu.

[sfriesel]

cloudinit hits the same problem when configured with {chef: {install_type: gems}}. It executes virtually the same commands like @migurski's original script

[agperson]

We're seeing this same error installing certain gems during an initial converge, i.e. chef_gem 'chef-handler-graphite' -- not sure why its picking up ohai 7.6 at all, but it sure breaks everything.

[lamont-granquist]

This works for me on ruby 1.9.3 and ruby 2.1.3. It only fails on ruby 1.8.7 (i don't have a ruby 1.9.2 to test right now, but its probably behaving like 1.8.7). Both 1.8.7 and 1.9.2 are past EOL and there's no security updates for those and we don't support those any more. We didn't intend to break them this hard, but it does look like this error is indicative of using unsupported ruby versions.

[lamont-granquist]

Here's the base problem:

% gem install ohai
Fetching: mime-types-1.25.1.gem (100%)
Successfully installed mime-types-1.25.1
Fetching: systemu-2.6.4.gem (100%)
Successfully installed systemu-2.6.4
Fetching: ffi-1.9.6.gem (100%)
Building native extensions.  This could take a while...
Successfully installed ffi-1.9.6
Fetching: libyajl2-1.2.0.gem (100%)
Building native extensions.  This could take a while...
Successfully installed libyajl2-1.2.0
Fetching: ffi-yajl-1.3.1.gem (100%)
Building native extensions.  This could take a while...
Successfully installed ffi-yajl-1.3.1
Fetching: mixlib-cli-1.5.0.gem (100%)
Successfully installed mixlib-cli-1.5.0
Fetching: mixlib-config-2.1.0.gem (100%)
Successfully installed mixlib-config-2.1.0
Fetching: mixlib-log-1.6.0.gem (100%)
Successfully installed mixlib-log-1.6.0
Fetching: mixlib-shellout-2.0.0.gem (100%)
ERROR:  Error installing ohai:
    mixlib-shellout requires Ruby version >= 1.9.3.

Its trying to install ohai 7.6.0 which pins to mixlib-shellout >= 2.0 which won't install on 1.8.7, and the fact that mixlib-shellout 2.0 isn't viable doesn't make it culled out of the depsolver.

So actually this is probably the result of releasing ohai 7.6.0 rather than yanking mixlib-shellout 1.6.0

This might be a good case for yanking ohai 7.6.0 (since it was released yesterday and most people wouldn't have it in Gemfile.locks yet, and then adding the version pin). If we add the version pin to ohai 8.0 and release it, then we'll still pick up 7.6.0 on old rubies and still be broken.

[agperson]

Using omnibus installer of 11.14.6 it reports as (embedded) ruby 1.9.3 but dumps gems into a 1.9.1 folder? And the error is present.

[danielsdeleo]

I wonder if the rubygems version is relevant here? Rubygems has been getting a lot smarter about version conflicts over time

[danielsdeleo]

BTW, the directories that Ruby uses to store stuff are based on the ruby binary interface version, so it's expected that ruby 1.9.3 uses a ruby 1.9.1 directory.

[gravitystorm]

@lamont-granquist I get the same problem on 1.9.3 - it's not anything to do with 1.8.7.

vagrant@vagrant-ubuntu-trusty-64:~$ ruby -v
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
sudo gem install chef
ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: chef requires mixlib-shellout (~> 1.4); ohai requires mixlib-shellout (< 3.0, >= 2.0.0.rc.0)

The root problem is that the ohai 7.6.0 release changed the mixlib-shellout dependencies from those in 7.4.0, and which are now incompatible with the chef -> mixlib-shellout dependencies in chef 11.16.4.

chef 11.16.4 depends on mixlib-shellout ~>1.4
chef 11.16.4 depends on ohai ~> 7.4
ohai 7.4.0 depended on mixlib-shellout ~> 1.2
ohai 7.6.0 now depends on  mixlib-shellout < 3.0, >= 2.0.0.rc.0 

So when 7.4.0 was the latest, that constraints were ~>1.4 and ~>1.2 which is resolvable (i.e. 1.x where x > 4). Now that 7.6.0 is released, the constraints are not resolvable since it can't be both ~>1.4 and also >= 2.0.0

There are a bunch of solutions, some easier than others:

• release chef 11.16.5 with the ohai dependency fixed as ohai =7.4.0
• yank ohai 7.6.0 and re-release as 8.0.0 - changing the dependency constraints can be seen as changing the gem's external api, I guess
• release chef 12.0.0 - the mixlib-shellout dependency was changed to match ohai in a463b6d (chef 11 would still be broken, of course)
• release chef 11.16.5 with mixlib-shellout dependency upgraded to match ohai 7.6.0 constraint (and of course change the ohai constraint to ~>7.6.0
• something else?

The first one seems the least likely to break along with being the least amount of work.

[lamont-granquist]

Okay, this is the old rubygems transitive depsolving bug then (json 1.7.7 + chef + berkshelf issue). Clearly there's a solution if people are able to install ohai 7.4.0 and everything works. I can also install fine on up-to-date 1.9.3 and 2.1.3.

That matches with the omnibus version of chef having the same problem since the rubygems version there is ancient.

My understanding was that chef-client 11.x was supposed to pin to ohai 7.4 while chef-client 12.x was supposed to pin to ohai 7.6 but that does not seem to be what happened. Since ohai 7.6 pulls in mixlib-shellout 2.x it must be excluded by chef-client 11.x (which cannot pull in mixlib-shellout 2.x), we can't have a dep of a dep pulling in mixlib-shellout 2.x on chef 11.x.

So the correct solution is to yank 7.6.0 and release 8.0.

Releasing chef-client 11.x is also more than an order of magnitude more complicated than releasing the other gems due to rebuilding and releasing the omnibus artifacts, so we aren't going to be doing that unless we absolutely have to.

[migurski]

I agree that yanking ohai 7.6.0 and treating the incompatible dependencies as an API change sounds like a great way to resolve this.

[sersut]

Thanks for help all. Here is the plan we will start to execute pretty soon to resolve this:

1. Yank ohai 7.6.0 in order to stop the brokenness
2. Update community about yanking ohai 7.6.0 with preliminary info & more info coming soon.
3. Mailing List + Blog Post about details for recent yankings / releases
4. Release ohai 8.0.0 with required_ruby_version >= 2.0.
5. Release chef 12.0.0 with ohai ~> 8.0 & shellout ~> 2.0 (chef 11 stays at ohai ~> 7.0 & shellout ~> 1.0)

[jaym]

@sersut 👍

[schisamo]

@sersut 👍

[scotthain]

👍

[sersut]

Thanks again for working with us during this issue guys. Ohai 8.0.1 is now released and we will be releasing Chef 12.0.0 soon.

I'll be closing this issue. We will be on the watchout on Github for any potential issues 😄

👍