Asking for 9.3, but getting 8.4 about postgresql HOT 12 CLOSED

Things often don't go expected if 8.4 is already installed (e.g. if you run the recipe once, then later run again with 9.3 set) - I recommend purging the 8.4 packages completely, then retrying the recipe

from postgresql.

I ran "yum remove" on the four 8.4 packages, but that didn't change any behavior. I wound up with 8.4 being installed by Chef. Then I removed 8.4, installed the 9.3 packages manually, and ran my recipe again -- it installed 8.4. I wonder if I'm wrong to use "override['postgresql']['version'] = '9.3'" in my attributes, but it does install the right Yum repository, so that doesn't seem like the obvious mistake.

[2014-09-04T09:00:23-04:00] INFO: Processing package[pgdg-centos93] action install (postgresql::yum_pgdg_postgresql line 43)
[2014-09-04T09:00:23-04:00] DEBUG: package[pgdg-centos93] checking rpm status
[2014-09-04T09:00:23-04:00] DEBUG: package[pgdg-centos93] checking install state
[2014-09-04T09:00:23-04:00] DEBUG: package[pgdg-centos93] current version is 9.3-1
[2014-09-04T09:00:23-04:00] DEBUG: package[pgdg-centos93] is already installed - nothing to do
[2014-09-04T09:00:23-04:00] INFO: Processing package[postgresql-devel] action install (postgresql::client line 36)
[2014-09-04T09:00:26-04:00] DEBUG: package[postgresql-devel] checking yum info for postgresql-devel
[2014-09-04T09:00:26-04:00] DEBUG: package[postgresql-devel] installed version: (none) candidate version: 8.4.20-1.el6_5
[2014-09-04T09:00:26-04:00] INFO: package[postgresql-devel] installing postgresql-devel-8.4.20-1.el6_5 from updates repository

from postgresql.

👍 seeing the same behavior. I'm guessing that the version information is being set correctly but the package list default['postgresql']['client']['packages'] had already been defined with the default version -- in my case, 9.1?

override.postgresql.enable_pgdg_apt = true
override.postgresql.version = '9.3'
...
...
...
Recipe: postgresql::client
  * package[postgresql-client-9.1] action install
    - install version 9.1.14-1.pgdg12.4+1 of package postgresql-client-9.1

override.postgresql.enable_pgdg_apt = true
override.postgresql.version = '9.3'
override.postgresql.client.packages = ["postgresql-client-9.3","libpq-dev"]
...
...
...
Recipe: postgresql::client
  * package[postgresql-client-9.3] action install
    - install version 9.3.5-1.pgdg12.4+1 of package postgresql-client-9.3

from postgresql.

@gkuchta I think you're right about the attribute overriding. If you look at the attributes/default.rb file, for many platforms that have the version number in the package names, they are being interpolated into the string. There are alternate ways of achieving this (https://coderanger.net/derived-attributes/), but given this cookbook doesn't use them, you will need to ensure you override the attributes in a way that gets processed before this cookbooks attributes file.

I would recommend having a wrapper cookbook e.g. my_db which depends on this postgresql cookbook, and doing the override in my_db/attributes/default.rb via override['postgresql']['version'] = '9.3'. I think overriding in a role, or environment should also work. Overriding in the recipe portion of another cookbook will definitely NOT work, because during a chef run, all attribute files of all cookbooks are parsed before any recipe files.

from postgresql.

I will go with the wrapper cookbook, then. (I love that the "Doing Wrapper Cookbooks Right" article on getchef.com uses the postgresql cookbook as its example.)

Thanks again for looking at this and helping make some sense of it to me.

from postgresql.

@jeremyolliver I'm using a wrapper cookbook as described, and today I noticed that it only changes the postgres client version, the server seems to want to default to 9.1.14 for whatever reason on Ubuntu 12.04.5

Edit: The fix that worked for me was to specify the version in the node json file:

{
    "postgresql": {
         "version": "9.3"
    }
}

from postgresql.

Seems like this issue is resolved by correctly managing the way your attributes are assigned so that at run time the cookbook has everything in order. I will close this for now as not a issue for enhancements at this time. If you feel your question hasn't been resolved please feel free to continue the discussion or propose any needed change in a PR.

from postgresql.

@jeremyolliver I tryed using the wrapper cookbook as @nozpheratu did and it does install postgres, but it doesn't really work correctly, and I checked the postgres conf files and some of the value were still set as 9.1.

So I tryed this option with json node with chef-solo and it worked.

The README says that we just have to change:
node['postgresql']['enable_pgdg_apt']
node['postgresql']['client']['packages']
node['postgresql']['server]['packages']
node['postgresql']['version']

As I understood if I do use the wrapper cookbook I have to replace all the attributes that are affected by the "version", and if I use the json node it somehow changes the version before evaluating those attributes that use the version.

Can someone clarify why with json node attributes it changes the version before evaluating the other attributes? (I couldn't understand how that part works)
And will this be a recommended way to do it ? Does it work for chef-server also ?

from postgresql.

@furver Attributes are a kind of tricky thing to get right sometimes - it really comes down to the order that they get loaded - as well as the level of priority given to them. See the section Attribute Precedence on https://docs.getchef.com/chef_overview_attributes.html for more info on the priority levels. Overriding the node json data is both loaded first, so guaranteed to be set before this cookbooks attributes are parsed - meaning the other derived attributes pick up the new version number, and also the highest level of priority ensuring they aren't changed back to the default.

I should mention that no, you can't set the node json for chef-server. The best workaround there is probably to override all the attributes that are computed from the version. My previous comment here suggests a different way this cookbook could write those attributes which would mean you only need to override one, but given that isn't the current state, I think you'll have to override them all

from postgresql.

@jeremyolliver thanks for answering.
I was considering using the json node, but since it doesn't work for chef server we will need something else. What about the roles that you mentioned before is it a good idea ? I read about and found quite a lot of people that discourage using it.
I got how the attributes work and how to override them. I actually wrote here hoping someone would say that they are planning to use the attributes the way you wrote before, but that doesn't seem to be the case. :D
So I wanted to make sure that overriding all the attributes would really be the "recommended" way.

from postgresql.

Loom at my solution on #234

from postgresql.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from postgresql.