Attributes that interpolate the node's postgres version remain at 9.1 (the default) when node overrides postgres version about chef-postgresql HOT 11 CLOSED

The workaround is to override all of the paths for the node attribute like so:

override["postgresql"]["version"] = "9.2"
override["postgresql"]["data_directory"]                  = "/var/lib/postgresql/#{node["postgresql"]["version"]}/main"
override["postgresql"]["hba_file"]                        = "/etc/postgresql/#{node["postgresql"]["version"]}/main/pg_hba.conf"
override["postgresql"]["ident_file"]                      = "/etc/postgresql/#{node["postgresql"]["version"]}/main/pg_ident.conf"
override["postgresql"]["external_pid_file"]               = "/var/run/postgresql/#{node["postgresql"]["version"]}-main.pid"

from chef-postgresql.

I suspect that this has gone unnoticed due to Chef's ordering of loading attributes - so it can sometimes work. From the Chef wiki: "When Chef loads cookbook attribute files, it does so in alphabetical order for all the cookbooks". See here.

from chef-postgresql.

@freshtonic thanks for the report. This is the first I have heard of this issue occurring. Would you be willing to submit a pull request to update the README with your notes?

Thanks for your time!

from chef-postgresql.

Sure, no problem.

from chef-postgresql.

I'll try my hand at a pull request that fixes the issue rather than works around it.

from chef-postgresql.

@phlipper I think the correct solution (at least until Opscode give us lazy attribute evaluation) is to perform the interpolation entirely in the recipes. For some files this already happens: pg_version is interpolated into other strings right there in the recipe.

I'm not familiar with other's specific Postgres deployment idiosynracies, and so I don't know who's downstream cookbooks will break if I make the recipes self-consistent with respect to filename generation.

Is this a reasonable approach?

from chef-postgresql.

@freshtonic I can't totally envision what you mean at the moment, but it sounds like a reasonable approach :) Go ahead and take a stab at it and we'll use that as a starting point to work through this issue.

Thanks so much for your time and help, I really appreciate it!

from chef-postgresql.

@freshtonic have you had an opportunity to look in to this issue any more?

from chef-postgresql.

@phlipper the core problem is that changing

default["postgresql"]["version"]

to another value in the attributes file will not cause

# FILE LOCATIONS
default["postgresql"]["data_directory"]                  = "/var/lib/postgresql/#{node["postgresql"]["version"]}/main"
default["postgresql"]["hba_file"]                        = "/etc/postgresql/#{node["postgresql"]["version"]}/main/pg_hba.conf"
default["postgresql"]["ident_file"]                      = "/etc/postgresql/#{node["postgresql"]["version"]}/main/pg_ident.conf"
default["postgresql"]["external_pid_file"]               = "/var/run/postgresql/#{node["postgresql"]["version"]}-main.pid"

to be recalculated.

Right now, the default postgresql version is 9.2. If a user of this recipe wants to install 9.1, it is insufficient to override just the postgresql version attribute. It is required that the user also override the FILE LOCATIONS attributes in their own recipes too. Like so:

override["postgresql"]["version"] = "9.2"
# FILE LOCATIONS
override["postgresql"]["data_directory"]                  = "/var/lib/postgresql/#{node["postgresql"]["version"]}/main"
override["postgresql"]["hba_file"]                        = "/etc/postgresql/#{node["postgresql"]["version"]}/main/pg_hba.conf"
override["postgresql"]["ident_file"]                      = "/etc/postgresql/#{node["postgresql"]["version"]}/main/pg_ident.conf"
override["postgresql"]["external_pid_file"]               = "/var/run/postgresql/#{node["postgresql"]["version"]}-main.pid"

All I can offer is a documentation fix in the README that informs users that they need to override the derived attributes too.

This cannot be solved cleanly (i.e. by overriding only the version attribute) until the version 11.0 of chef is released. My understanding is that a user's override will be applied earlier in attribute resolution, so in theory overriding only the version (in this case) will work fine.

See This Chef Issue

from chef-postgresql.

Made a pull request #14

from chef-postgresql.

Closed by #14

from chef-postgresql.