Opsworks PostgreSQL Install Failures

[richseviora]

setup is failing (V 11.10) as a result of the change to add Postgresql to the opsworks rails:configure recipe.

I am receiving the following error message in my log. Removing my existing user recipes to install postgres93/94 did not fix the issue. Any thoughts on where this is coming from? The error message is not all that helpful.

I will be overriding the client sql recipes for the time being.

[2015-11-02T18:29:36+00:00] WARN: package[postgresql-devel] matched multiple Provides for postgresql-devel but we can only use the first match: postgresql8-devel. Please use a more specific version.
[2015-11-02T18:29:36+00:00] INFO: package[postgresql-devel] installing postgresql8-devel-8.4.20-3.50.amzn1 from amzn-main repository

================================================================================
Error executing action `install` on resource 'package[postgresql-devel]'
================================================================================

Chef::Exceptions::Exec
----------------------
returned 1, expected 0

Resource Declaration:
---------------------
# In /var/lib/aws/opsworks/cache.stage2/cookbooks/opsworks_postgresql/recipes/client_install.rb

1: package "postgresql-devel" do
2:   package_name value_for_platform(
3:     ["centos","redhat","fedora","amazon"] => {"default" => "postgresql-devel"},
4:     "ubuntu" => {"default" => "libpq-dev"}
5:   )
6:   action :install
7: end
8: 

Compiled Resource:
------------------
# Declared in /var/lib/aws/opsworks/cache.stage2/cookbooks/opsworks_postgresql/recipes/client_install.rb:1:in `from_file'

package("postgresql-devel") do
action [:install]
retries 0
retry_delay 2
package_name "postgresql8-devel"
version "8.4.20-3.50.amzn1"
cookbook_name "opsworks_postgresql"
recipe_name "client_install"
end

[ausmith]

We're also experiencing this issue. https://github.com/aws/opsworks-cookbooks/commit/3e431035cf5f06edb0e2253d2e8316f60ad49297 is the commit that added this to the OpsWorks Cookbooks for Chef 11.10 support. This recipe change attempts to install postgresql-devel, sees multiple versions of the software package, and Chef grabs the "top" version (postgresql8-devel-8.4.20-3.50.amzn1) and attempts to install it.

That would be totally fine except for 2 things: 1) We don't want the oldest version because we want to use version X of the postgresql-devel and postgresql packages. 2) We already have a version of the postgresql-devel and postgresql packages installed on our servers.

Fortunately, the package short-circuits itself and stops the install process because there's currently another postgresql package on the system and recognizes it shouldn't overwrite those existing libraries. This is revealed by attempting a postgresql8-devel install manually with postgresql93-devel already installed on the system:

[root@my-host ~]$ yum install postgresql8-devel
Loaded plugins: priorities, upgrade-helper
amzn-main/2015.03                                                                                                                | 2.1 kB     00:00
amzn-updates/2015.03                                                                                                             | 2.3 kB     00:00
epel/x86_64/metalink                                                                                                             |  13 kB     00:00
961 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package postgresql8-devel.x86_64 0:8.4.20-3.50.amzn1 will be installed
--> Processing Dependency: postgresql8(x86-64) = 8.4.20-3.50.amzn1 for package: postgresql8-devel-8.4.20-3.50.amzn1.x86_64
--> Processing Dependency: postgresql8-libs(x86-64) = 8.4.20-3.50.amzn1 for package: postgresql8-devel-8.4.20-3.50.amzn1.x86_64
--> Running transaction check
---> Package postgresql8.x86_64 0:8.4.20-3.50.amzn1 will be installed
---> Package postgresql8-libs.x86_64 0:8.4.20-3.50.amzn1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================================
 Package                                 Arch                         Version                                  Repository                          Size
========================================================================================================================================================
Installing:
 postgresql8-devel                       x86_64                       8.4.20-3.50.amzn1                        amzn-updates                       910 k
Installing for dependencies:
 postgresql8                             x86_64                       8.4.20-3.50.amzn1                        amzn-updates                       3.5 M
 postgresql8-libs                        x86_64                       8.4.20-3.50.amzn1                        amzn-updates                       238 k

Transaction Summary
========================================================================================================================================================
Install  1 Package (+2 Dependent packages)

Total size: 4.6 M
Installed size: 18 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test

Transaction check error:
  file /usr/include/pgsql/server/libpq/libpq-fs.h from install of postgresql8-devel-8.4.20-3.50.amzn1.x86_64 conflicts with file from package postgresql93-devel-9.3.9-1.59.amzn1.x86_64
  file /usr/include/pgsql/server/pg_config_manual.h from install of postgresql8-devel-8.4.20-3.50.amzn1.x86_64 conflicts with file from package postgresql93-devel-9.3.9-1.59.amzn1.x86_64
  file /usr/include/pgsql/server/pg_config_os.h from install of postgresql8-devel-8.4.20-3.50.amzn1.x86_64 conflicts with file from package postgresql93-devel-9.3.9-1.59.amzn1.x86_64
...

This behavior is triggered for any OpsWorks stack of ours that has a Rails and postgresql RDS layer attached to it. We are toying with a few solutions: 1) Completely remove the RDS layer from the stack and send down the DB configuration info from the Stack Settings, including password. 2) Roll our stack back to Chef 0.9 as the supporting OpsWorks provided recipes do not include this package installation step. 3) Remove the Rails app layer and manually pick and choose what recipes we want run from the OpsWorks cookbooks. 4) Leave OpsWorks for CodeDeploy.

[richseviora]

@ausmith It may not be necessary to look at anything that drastic for a fix. I was able to override the client_install.rb file with the changes you'd suspect (super obvious recipe, https://gist.github.com/richseviora/9a0871dd3fd8890f1e3e)

[ausmith]

@richseviora good call! I will pursue overriding the offending recipe until the issue is corrected. Thanks!

[richseviora]

@ausmith Delighted to help :) Cheers!

[ausmith]

@richseviora Greatly appreciate you pointing out being able to override recipes! We're in working order again and hopefully others can find this issue.

[brentfisher]

Yay!

[npflood]

Thanks for this temporary fix guys! Any chance you could point me in the right direction on where to put the contents of this Gist to successfully override the recipe? I tried copying it to my custom chef recipe repository but saw no change.

[richseviora]

@npflood you'll need the following: /opsworks_postgresql/metadata.rb: Standard metadata format. /opsworks_postgresql/recipes/client_install.rb: Gist contents here!

I've updated the gist accordingly.

[npflood]

Thanks @richseviora, I had missed the metadata file. Should have checked my logs better.

[dougbradbury]

Update to this issue: You can now specify in your json configuration which version of postgres you want installed

{
  "opsworks_postgresql": {
    "devel_package": "postgresql95-devel",
    "client_package": "postgresql95"
  }
}