[chef] Re: Re: [COOK-1406] Roadmap for chef-omnibus + postgresql?

Chronological Thread 
  • From: Jay Levitt < >
  • To:
  • Subject: [chef] Re: Re: [COOK-1406] Roadmap for chef-omnibus + postgresql?
  • Date: Tue, 25 Sep 2012 09:40:04 -0400

Lamont Granquist wrote:
> On 9/24/12 11:30 AM, Jay Levitt wrote:
>> Best I can tell, Joshua Timberman has finished the refactoring of mysql,
>> postgresql, and database cookbooks, and chef 10.14 has been released,
>> both of which were precursors to untangling the chicken-and-egg mess
>> of needing a libpq that's compatible with Omnibus ruby.
>> Soooo.. what's left? I'm currently installing chef via ubuntu-gems, but
>> that creates its own problems when I replace system ruby with rvm..
>> http://tickets.opscode.com/browse/COOK-1406

The problem comes with newer systems where the openssl in the system is
incompatible with the one that omnibus ships. The problem there is that the
ruby binary in omnibus is linked against the openssl library in omibus, but
the pg libraries on the system are linked against the system pg libraries
and if they use different ABIs to talk to openssl when you try to 'chef_gem'
install the pg gem you'll wind up with the omnibus version of openssl linked
in, and the pg libraries will barf with unresolved symbols because they want
the later version of the openssl libs.

Upgrading the openssl libraries in omnibus would just shove this problem
around to different distros (now centos5/6, and ubuntu-10.04 would be
busted). Shipping pg binaries in omnibus is another solution but its a bit
annoying because we probably want to match the pg version against the
version shipping with the distro, and that hasn't been what omnibus has been
about, its been to ship a consistent version of the libraries in it 

I'm not so sure about that. On the one hand, psql (and therefore libpq) is considered backwards-compatible enough that committers just proposed removing the "WARNING: Some features might not work" when you connect to older servers.


On the other hand, this doesn't help if you have a *newer* version in the distro, specifically a newer, incompatible server version that this libpq needs to talk to. This can be solved by revving pg versions often enough in omnibus.

On the third hand, nothing helps if your server is on a different machine, and THAT machine has a newer version of the server than this machine's libpq, and chef doesn't even try to protect you here. So why do we care more if the server's on the same machine?

I'm new here, but this feels OK to me; we're (presumably) not doing complex database access in chef recipes that requires bleeding-edge libpq (if you're even on a bleeding-edge distro); we're creating a database and some roles and other scaffoldy stuff.

What do you think?

The better solution is probably to compile the pg libraries from source,
making sure to get -I and -L flags right to pick up the omnibus openssl and
install those in the omnibus directory. Do that at compile time after
installing build-essentials, but before calling chef_gem.

Which cookbook should this go in? I could take a crack at it, though anything that slows the first converge makes me sad, and Postgres compiles take two minutes on a fast machine (though that's the whole server; client-only may be faster).

Archive powered by MHonArc 2.6.16.