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

Seeing version incompatibilities on installation, Ubuntu 14.04 #2517

Closed
migurski opened this Issue Dec 2, 2014 · 18 comments

Comments

Projects
None yet
@migurski
Copy link

migurski commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor

jaym commented Dec 2, 2014

~> 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

This comment has been minimized.

Copy link
Author

migurski commented Dec 2, 2014

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 comment has been minimized.

Copy link

caboteria commented Dec 2, 2014

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

This comment has been minimized.

Copy link

sfriesel commented Dec 2, 2014

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

@agperson

This comment has been minimized.

Copy link

agperson commented Dec 2, 2014

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.

migurski added a commit to openaddresses/machine that referenced this issue Dec 2, 2014

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 2, 2014

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

This comment has been minimized.

Copy link

agperson commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Member

danielsdeleo commented Dec 2, 2014

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

@danielsdeleo

This comment has been minimized.

Copy link
Member

danielsdeleo commented Dec 2, 2014

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

This comment has been minimized.

Copy link

gravitystorm commented Dec 2, 2014

@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

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Author

migurski commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor

sersut commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor

jaym commented Dec 2, 2014

@sersut 👍

@schisamo

This comment has been minimized.

Copy link
Member

schisamo commented Dec 2, 2014

@sersut 👍

@scotthain

This comment has been minimized.

Copy link
Contributor

scotthain commented Dec 2, 2014

👍

joshmyers pushed a commit to joshmyers/capistrano-cook that referenced this issue Dec 2, 2014

migurski added a commit to openaddresses/machine that referenced this issue Dec 3, 2014

@sersut

This comment has been minimized.

Copy link
Contributor

sersut commented Dec 4, 2014

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 😄

👍

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