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

[Jay Levitt < >]

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 
> everywhere.

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.

http://archives.postgresql.org/pgsql-hackers/2012-08/msg01168.php

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).

> >