Chef-client gem install --pre doesn't find second level dependencies?


#1

Am I missing something here? I’ve tried a few times now doing a clean
install of chef only for client install purposes on both RHEL and
ubuntu (10.04) using rubygems. It seems that it when installing a
prerelease version, you can’t find second level dependencies or
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y
INFO: gem install -y is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
ERROR: Error installing chef:
mixlib-authentication requires mixlib-log (>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it
couldn’t find mixlib-log ?? But that is there and you can install it
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log
Successfully installed mixlib-log-1.3.0
1 gem installed
Installing ri documentation for mixlib-log-1.3.0…
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but
this is irritating. Seems like I have to manually specify all the
dependencies that don’t have a prerelease version first and then I can
install chef --pre? I know this will go away once all the chef bits
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll
just keep happening. On the other hand, I might just be missing
something that would make this a non-issue.

KC


#2

What version of ruby are you using, KC? I think this is actually
caused by Rubygems no longer supporting particular versions of ruby.

Adam

On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Am I missing something here? I’ve tried a few times now doing a clean
install of chef only for client install purposes on both RHEL and
ubuntu (10.04) using rubygems. It seems that it when installing a
prerelease version, you can’t find second level dependencies or
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y
INFO: gem install -y is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
ERROR: Error installing chef:
mixlib-authentication requires mixlib-log (>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it
couldn’t find mixlib-log ?? But that is there and you can install it
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log
Successfully installed mixlib-log-1.3.0
1 gem installed
Installing ri documentation for mixlib-log-1.3.0…
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but
this is irritating. Seems like I have to manually specify all the
dependencies that don’t have a prerelease version first and then I can
install chef --pre? I know this will go away once all the chef bits
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll
just keep happening. On the other hand, I might just be missing
something that would make this a non-issue.

KC


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#3

That might make sense on RHEL <= 5, but Ubuntu 10.04 comes with a
pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.

On Tuesday, April 19, 2011, Adam Jacob adam@opscode.com wrote:

What version of ruby are you using, KC? I think this is actually
caused by Rubygems no longer supporting particular versions of ruby.

Adam

On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Am I missing something here? I’ve tried a few times now doing a clean
install of chef only for client install purposes on both RHEL and
ubuntu (10.04) using rubygems. It seems that it when installing a
prerelease version, you can’t find second level dependencies or
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y
INFO: gem install -y is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
ERROR: Error installing chef:
mixlib-authentication requires mixlib-log (>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it
couldn’t find mixlib-log ?? But that is there and you can install it
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log
Successfully installed mixlib-log-1.3.0
1 gem installed
Installing ri documentation for mixlib-log-1.3.0…
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but
this is irritating. Seems like I have to manually specify all the
dependencies that don’t have a prerelease version first and then I can
install chef --pre? I know this will go away once all the chef bits
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll
just keep happening. On the other hand, I might just be missing
something that would make this a non-issue.

KC


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Mark J. Reed markjreed@gmail.com


#4

kc@t5400:~$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

kc@t5400:~$ gem -v
1.3.5

On Tue, Apr 19, 2011 at 5:17 PM, Mark J. Reed markjreed@gmail.com wrote:

That might make sense on RHEL <= 5, but Ubuntu 10.04 comes with a
pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.

On Tuesday, April 19, 2011, Adam Jacob adam@opscode.com wrote:

What version of ruby are you using, KC? I think this is actually
caused by Rubygems no longer supporting particular versions of ruby.

Adam

On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Am I missing something here? I’ve tried a few times now doing a clean
install of chef only for client install purposes on both RHEL and
ubuntu (10.04) using rubygems. It seems that it when installing a
prerelease version, you can’t find second level dependencies or
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y
INFO: gem install -y is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
ERROR: Error installing chef:
mixlib-authentication requires mixlib-log (>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it
couldn’t find mixlib-log ?? But that is there and you can install it
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log
Successfully installed mixlib-log-1.3.0
1 gem installed
Installing ri documentation for mixlib-log-1.3.0…
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but
this is irritating. Seems like I have to manually specify all the
dependencies that don’t have a prerelease version first and then I can
install chef --pre? I know this will go away once all the chef bits
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll
just keep happening. On the other hand, I might just be missing
something that would make this a non-issue.

KC


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Mark J. Reed markjreed@gmail.com


#5

I believe you need to upgrade rubygems - can you tell me what happens
if you do a gem update --system?

On Wed, Apr 20, 2011 at 12:07 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

kc@t5400:~$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

kc@t5400:~$ gem -v
1.3.5

On Tue, Apr 19, 2011 at 5:17 PM, Mark J. Reed markjreed@gmail.com wrote:

That might make sense on RHEL <= 5, but Ubuntu 10.04 comes with a
pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.

On Tuesday, April 19, 2011, Adam Jacob adam@opscode.com wrote:

What version of ruby are you using, KC? I think this is actually
caused by Rubygems no longer supporting particular versions of ruby.

Adam

On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Am I missing something here? I’ve tried a few times now doing a clean
install of chef only for client install purposes on both RHEL and
ubuntu (10.04) using rubygems. It seems that it when installing a
prerelease version, you can’t find second level dependencies or
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y
INFO: gem install -y is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
ERROR: Error installing chef:
mixlib-authentication requires mixlib-log (>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it
couldn’t find mixlib-log ?? But that is there and you can install it
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log
Successfully installed mixlib-log-1.3.0
1 gem installed
Installing ri documentation for mixlib-log-1.3.0…
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but
this is irritating. Seems like I have to manually specify all the
dependencies that don’t have a prerelease version first and then I can
install chef --pre? I know this will go away once all the chef bits
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll
just keep happening. On the other hand, I might just be missing
something that would make this a non-issue.

KC


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Mark J. Reed markjreed@gmail.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#6

What version of rubygems is required?

ERROR: While executing gem … (RuntimeError)
gem update --system is disabled on Debian. RubyGems can be updated
using the official Debian repositories by aptitude or apt-get.

On Wed, Apr 20, 2011 at 2:28 PM, Adam Jacob adam@opscode.com wrote:

I believe you need to upgrade rubygems - can you tell me what happens
if you do a gem update --system?

On Wed, Apr 20, 2011 at 12:07 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

kc@t5400:~$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

kc@t5400:~$ gem -v
1.3.5

On Tue, Apr 19, 2011 at 5:17 PM, Mark J. Reed markjreed@gmail.com wrote:

That might make sense on RHEL <= 5, but Ubuntu 10.04 comes with a
pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.

On Tuesday, April 19, 2011, Adam Jacob adam@opscode.com wrote:

What version of ruby are you using, KC? I think this is actually
caused by Rubygems no longer supporting particular versions of ruby.

Adam

On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Am I missing something here? I’ve tried a few times now doing a clean
install of chef only for client install purposes on both RHEL and
ubuntu (10.04) using rubygems. It seems that it when installing a
prerelease version, you can’t find second level dependencies or
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y
INFO: gem install -y is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
ERROR: Error installing chef:
mixlib-authentication requires mixlib-log (>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it
couldn’t find mixlib-log ?? But that is there and you can install it
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log
Successfully installed mixlib-log-1.3.0
1 gem installed
Installing ri documentation for mixlib-log-1.3.0…
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but
this is irritating. Seems like I have to manually specify all the
dependencies that don’t have a prerelease version first and then I can
install chef --pre? I know this will go away once all the chef bits
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll
just keep happening. On the other hand, I might just be missing
something that would make this a non-issue.

KC


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Mark J. Reed markjreed@gmail.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#7

On 20 April 2011 23:51, KC Braunschweig kcbraunschweig@gmail.com wrote:

What version of rubygems is required?

Forget 1.3.5 it’s about a bazillion years old. Gem update --system
will get you the latest (1.7.2 I think)

ERROR: While executing gem … (RuntimeError)
gem update --system is disabled on Debian. RubyGems can be updated
using the official Debian repositories by aptitude or apt-get.

REALLY_GEM_UPDATE_SYSTEM=yes
export $REALLY_GEM_UPDATE_SYSTEM
gem update --system

Remind me - is this for a workstation? You might like to try using
RVM and 1.9.2 if it is.

S.

Stephen Nelson-Smith,
Principal Consultant,
Atalanta Systems Ltd,
Web: http://agilesysadmin.net
Twitter: @lordcope
Skype: atalanta.systems
Telephone: +44 (0) 1223 969819
Mobile: +44 (0) 7917 101919

Atalanta Systems: The Agile Infrastructure Enablers
http://atalanta-systems.com


#8

http://help.opscode.com/kb/start/1-system-requirements-dependencies

Ruby 1.8.5, 1.8.6, 1.8.7, 1.9.1 or 1.9.2 with SSL bindings is required.

Rubygems Version 1.3.5 or greater. On Ubuntu and Debian Rubygems
should be installed from source.

Clearly I didn’t follow directions and tried to use standard ubuntu
rubygems. That being said, am I an asshole for thinking that
specifying installing from source is pretty lame? Seems like it is
going to be nothing but pain trying to justify (in a corporate env) a
tool that doesn’t either (1) work with the default platform packages
(of specified version) or (2) have vendor provided packages for the
supported OSs that are suitable replacements where there default
platform packages can’t be used. Yes, I can build rubygems from source
and roll my own package (as the Aegis guys have so helpfully done
recently for rhel/centos) but it seems like that is just creating
unnecessary barriers to entry for folks.

KC

On Wed, Apr 20, 2011 at 4:00 PM, Stephen Nelson-Smith
stephen@atalanta-systems.com wrote:

On 20 April 2011 23:51, KC Braunschweig kcbraunschweig@gmail.com wrote:

What version of rubygems is required?

Forget 1.3.5 it’s about a bazillion years old. Gem update --system
will get you the latest (1.7.2 I think)

ERROR: While executing gem … (RuntimeError)
gem update --system is disabled on Debian. RubyGems can be updated
using the official Debian repositories by aptitude or apt-get.

REALLY_GEM_UPDATE_SYSTEM=yes
export $REALLY_GEM_UPDATE_SYSTEM
gem update --system

Remind me - is this for a workstation? You might like to try using
RVM and 1.9.2 if it is.

S.

Stephen Nelson-Smith,
Principal Consultant,
Atalanta Systems Ltd,
Web: http://agilesysadmin.net
Twitter: @lordcope
Skype: atalanta.systems
Telephone: +44 (0) 1223 969819
Mobile: +44 (0) 7917 101919

Atalanta Systems: The Agile Infrastructure Enablers
http://atalanta-systems.com


#9

On Wed, Apr 20, 2011 at 4:13 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Clearly I didn’t follow directions and tried to use standard ubuntu
rubygems. That being said, am I an asshole for thinking that
specifying installing from source is pretty lame? Seems like it is
going to be nothing but pain trying to justify (in a corporate env) a
tool that doesn’t either (1) work with the default platform packages
(of specified version) or (2) have vendor provided packages for the
supported OSs that are suitable replacements where there default
platform packages can’t be used. Yes, I can build rubygems from source
and roll my own package (as the Aegis guys have so helpfully done
recently for rhel/centos) but it seems like that is just creating
unnecessary barriers to entry for folks.

We do provide deb packages in our apt repository for those who don’t
want to install from source. [1]

However, Chef 0.10 isn’t released yet; and we’re still at the release
candidate stage. The expectation for beta and RC releases is that
users are not going to install them directly into a production
environment. It is the period where we all test the software ourselves
and try to find any major bugs in the new release. If you don’t want
the hassle of building a development environment, I’d advise sticking
with the official releases. Shortly after the official final release
of 0.10.0, we’ll be putting up apt packages for 0.10, as described
recently on the Opscode blog [2]. I’m actually working on them right
now.

In either case, it isn’t that you need a newer version of Rubygems for
Chef 0.10, it is that older versions of Rubygems presumably aren’t as
good at resolving dependencies when using “–pre” to fetch
prereleases.

Bryan

[1] http://wiki.opscode.com/display/chef/Package+Installation+on+Debian+and+Ubuntu
[2] http://www.opscode.com/blog/2011/04/20/chef-0-9-16-and-ohai-0-6-2-debian-packages-available/


#10

We do provide deb packages in our apt repository for those who don’t
want to install from source. [1]

However, Chef 0.10 isn’t released yet; and we’re still at the release
candidate stage. The expectation for beta and RC releases is that
users are not going to install them directly into a production
environment. It is the period where we all test the software ourselves
and try to find any major bugs in the new release. If you don’t want
the hassle of building a development environment, I’d advise sticking
with the official releases. Shortly after the official final release
of 0.10.0, we’ll be putting up apt packages for 0.10, as described
recently on the Opscode blog [2]. I’m actually working on them right
now.

In either case, it isn’t that you need a newer version of Rubygems for
Chef 0.10, it is that older versions of Rubygems presumably aren’t as
good at resolving dependencies when using “–pre” to fetch
prereleases.

Totally understood regarding chef 0.10 and all beta/RC releases for
that matter.

My question was meant more generally as the requirements on that page
(specifically recommending source installed rubygems on ubuntu and
debian) are general chef requirements, not chef 0.10 specific. While I
wouldn’t have hit this particular issue had I been installing a non
prerelease version, assumably I would have hit some issue or other or
else you wouldn’t be recommending installing rubygems from source for
all versions.

KC


#11

On Wed, Apr 20, 2011 at 4:35 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

Totally understood regarding chef 0.10 and all beta/RC releases for
that matter.

My question was meant more generally as the requirements on that page
(specifically recommending source installed rubygems on ubuntu and
debian) are general chef requirements, not chef 0.10 specific. While I
wouldn’t have hit this particular issue had I been installing a non
prerelease version, assumably I would have hit some issue or other or
else you wouldn’t be recommending installing rubygems from source for
all versions.

The deal here is that Debian and Ubuntu make a series of policy
decisions about how to structure the libraries they ship with the
operating system. That’s cool - it’s the reason distributions exist,
after all. Next to that is the evolving ruby ecosystem - ruby itself
moves forward, bugs are fixed, and rubygems continues to become the
most common way to build and deploy ruby applications. Occasionally
those policy decisions conflict - in this case, Debian and Ubuntu both
ship with old versions of rubygems that also have tweaked library
paths from the norm (specifically, there is an issue with where
binaries are placed.)

So we make choices - in this case, we advise people to no longer run
the debian/ubuntu version of rubygems, and we work to get a change in
policy. That takes time, and so in the mean-time we guide people down
the path we know will result in a system that behaves as you would
expect.

The future solution to this problem will be full-stack installers
delivered both as stand-alone installable binaries and native
packages, but with the entire dependency chain included. That this is
the right solution is starting to be pretty widely embraced - you can
see the evidence in several past package maintainers for chef moving
to a model exactly like this.

Best,
Adam


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#12

On Wed, Apr 20, 2011 at 9:53 PM, Adam Jacob adam@opscode.com wrote:

The future solution to this problem will be full-stack installers
delivered both as stand-alone installable binaries and native
packages, but with the entire dependency chain included. That this is
the right solution is starting to be pretty widely embraced - you can
see the evidence in several past package maintainers for chef moving
to a model exactly like this.

That’s exactly what I was hoping for. Is there a particular person or
group or wiki page specific to this effort? I definitely want to keep
up on the progress and hopefully help out if I can.

KC


#13

On Wed, Apr 20, 2011 at 10:27 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

That’s exactly what I was hoping for. Is there a particular person or
group or wiki page specific to this effort? I definitely want to keep
up on the progress and hopefully help out if I can.

The Opscode effort can be found here:

https://github.com/adamhjk/fatty

You can find several other efforts (all of which are great):

This one uses RVM, and we’ve used it successfully with some customers:

The illustrious Matthew Kent has an excellent RVM based system for
CentOS as well:

I’ll get more data sent to the list about timing for an RC of the
Opscode built binaries.

Adam


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com