[chef-dev] Re: Ohai Ruby plugin: system ruby vs. running ruby?


Chronological Thread 
  • From: Brad Knowles < >
  • To: Daniel DeLeo < >
  • Cc: Brad Knowles < >, Chef Dev < >
  • Subject: [chef-dev] Re: Ohai Ruby plugin: system ruby vs. running ruby?
  • Date: Wed, 31 Aug 2011 15:25:37 -0500

On Aug 31, 2011, at 3:03 PM, Daniel DeLeo wrote:

> The change that I'm talking about is only related to how ohai collects data 
> about what ruby you have installed on the system. In Chef you can access 
> this data as node[:languages][:ruby]. Are you currently depending on this 
> data to return information about the system ruby?

Right now, we're just trying to figure out how to use Chef to help us rebuild 
our infrastructure so that it is more manageable and scalable.  The Omnibus 
installer goes a way towards that, but there is still the issue of having to 
set the user's path environment variable to include the 
/opt/opscode/embedded/bin directory before anything else because replacing 
the standard system-provided version of /usr/bin/ruby with symlinks to the 
new binary would cause all the old system-provided programs to break.

This is CentOS 5.6.  We're not back on RHEL4 or CentOS 5.1 or something -- 
this is relatively recent, to the degree that anything from RHEL/CentOS is 
recent.


We're not currently actually using Chef or ohai for anything, but if the code 
depends on a specific version of ruby & ruby-gems being installed and that 
version is different from what the standard system-provided version is, then 
you need to find a way to handle that exception within your own code.  This 
problem should be handled at compile/install time, so that I don't even have 
to modify the user path environment variable to include the new embedded 
subdirectory location.

You need to decide how you're going to handle potentially having several 
different versions of the same program installed (think multiple versions of 
python as well as ruby, etc...).  Our code doesn't care, at least not at the 
moment.  But you can be assured that whatever code we do have that might be 
sensitive to what version of what program is installed, we will handle the 
pathing/location issues to that within our own code.

-- 
Brad Knowles 
< >




Archive powered by MHonArc 2.6.16.

§