I am writing a wrapper cookbook for the community
postgresqlhttps://github.com/hw-cookbooks/postgresql cookbook.
Essentially, what I’m trying to do is override the following attributes:
When setting an override attribute in my wrapper cookbook to set the
version of PostgreSQL to “9.3” - the attributes within the PostgreSQL
cookbook that interpolate the version attribute do not receive the
attribute override.
Two notes:
I am able to set the postgresql version attribute to the desired "9.3"
in my .kitchen.yml file and the override works as you would expect/hope it
would. Meaning, all string interpolated attributes in the postgresql
cookbook receive “9.3” as its version.
After going through and overriding all attributes within the PostgreSQL
cookbook that use string interpolation, I ran into one last snag that has
stopped me from completing the cookbook. There are two attributes within
the PostgreSQL cookbook that set the "unix_socket_directory[-ies]"
attribute based on the PostgreSQL version. However, since the logic is
broken up into two separate lines, and the string interpolation doesn’t
pick up the correct version, it will actually add both attributes to the
postgresql.conf template - breaking the service.
I am writing a wrapper cookbook for the community postgresql https://github.com/hw-cookbooks/postgresql cookbook. Essentially,
what I'm trying to do is override the following attributes:
When setting an override attribute in my wrapper cookbook to set the
version of PostgreSQL to "9.3" - the attributes within the PostgreSQL
cookbook that interpolate the version attribute do not receive the
attribute override.
Two notes:
I am able to set the postgresql version attribute to the desired
"9.3" in my .kitchen.yml file and the override works as you would
expect/hope it would. Meaning, all string interpolated attributes in
the postgresql cookbook receive "9.3" as its version.
After going through and overriding all attributes within the
PostgreSQL cookbook that use string interpolation, I ran into one last
snag that has stopped me from completing the cookbook. There are two
attributes within the PostgreSQL cookbook that set the
"unix_socket_directory[-ies]" attribute based on the PostgreSQL
version. However, since the logic is broken up into two separate
lines, and the string interpolation doesn't pick up the correct
version, it will actually add both attributes to the postgresql.conf
template - breaking the service.
I am writing a wrapper cookbook for the community postgresqlhttps://github.com/hw-cookbooks/postgresql cookbook.
Essentially, what I'm trying to do is override the following attributes:
When setting an override attribute in my wrapper cookbook to set the
version of PostgreSQL to "9.3" - the attributes within the PostgreSQL
cookbook that interpolate the version attribute do not receive the
attribute override.
Two notes:
I am able to set the postgresql version attribute to the desired
"9.3" in my .kitchen.yml file and the override works as you would
expect/hope it would. Meaning, all string interpolated attributes in the
postgresql cookbook receive "9.3" as its version.
After going through and overriding all attributes within the
PostgreSQL cookbook that use string interpolation, I ran into one last snag
that has stopped me from completing the cookbook. There are two attributes
within the PostgreSQL cookbook that set the "unix_socket_directory[-ies]"
attribute based on the PostgreSQL version. However, since the logic is
broken up into two separate lines, and the string interpolation doesn't
pick up the correct version, it will actually add both attributes to the
postgresql.conf template - breaking the service.
Sorry for the short reply. Correct me if I'm wrong, but looking at the
source code, when you get a attribute key it returns the merged_attributes
key? So, if you were to override version and then use attribute_resolve to
re-load the attributes file on this line:
default['postgresql']['server']['packages'] = ["postgresql-#{node['
postgresql']['version']}"]
It should get the overridden key for "node['postgresql']['version'] and
work as expected?
I am writing a wrapper cookbook for the community postgresqlhttps://github.com/hw-cookbooks/postgresql cookbook.
Essentially, what I'm trying to do is override the following attributes:
When setting an override attribute in my wrapper cookbook to set the
version of PostgreSQL to "9.3" - the attributes within the PostgreSQL
cookbook that interpolate the version attribute do not receive the
attribute override.
Two notes:
I am able to set the postgresql version attribute to the desired
"9.3" in my .kitchen.yml file and the override works as you would
expect/hope it would. Meaning, all string interpolated attributes in the
postgresql cookbook receive "9.3" as its version.
After going through and overriding all attributes within the
PostgreSQL cookbook that use string interpolation, I ran into one last snag
that has stopped me from completing the cookbook. There are two attributes
within the PostgreSQL cookbook that set the "unix_socket_directory[-ies]"
attribute based on the PostgreSQL version. However, since the logic is
broken up into two separate lines, and the string interpolation doesn't
pick up the correct version, it will actually add both attributes to the
postgresql.conf template - breaking the service.
Yeah you can do that. You have to use default attrs in your library
cookbook and override attrs in all wrapper/role/etc cookbooks, then you
roll-your-own include_attributes to run in the recipe code of your
wrapper/role cookbook and slurp those in as early as possible. You have
to use override attrs or else when you load the library cookbooks attr
file you'll overwrite everything again. Generally we think that
solution has considerable code smell and isn't going to scale, and is
going down the path that has led us to force_override/force_default and
other hacks added to Chef to get people out of painting themselves into
a corner. The best practice is generally not to be setting attributes
in recipe code and to move attribute setting into attribute files in
order to get away from compile/converge issues in recipe code. In
simple cases, though, that does work.
On 1/13/14 6:04 PM, Greg Zapp wrote:
Hi,
Sorry for the short reply. Correct me if I'm wrong, but looking at
the source code, when you get a attribute key it returns the
merged_attributes key? So, if you were to override version and then
use attribute_resolve to re-load the attributes file on this line:
default['postgresql']['server']['packages'] =
["postgresql-#{node['postgresql']['version']}"]
It should get the overridden key for "node['postgresql']['version']
and work as expected?
You can re-load the attributes file from your recipe.
On Tue, Jan 14, 2014 at 2:01 PM, Lamont Granquist
<lamont@opscode.com <mailto:lamont@opscode.com>> wrote:
wrapper/role cookbooks don't work with those. either you need
to use roles, or you need to override all the computed
attributes in the cookbook.
see: https://tickets.opscode.com/browse/CHEF-4837
On 1/13/14 12:02 PM, Bill Young wrote:
Hello All,
I am writing a wrapper cookbook for the community postgresql
<https://github.com/hw-cookbooks/postgresql> cookbook.
Essentially, what I'm trying to do is override the following
attributes:
default['postgresql']['enable_pgdg_apt'] = false
default['postgresql']['version'] = "9.1"
However, many of the attributes within the community
postgresql cookbook use string interpolation for the version.
Example:
default['postgresql']['server']['packages'] =
["postgresql-#{node['postgresql']['version']}"]
When setting an override attribute in my wrapper cookbook to
set the version of PostgreSQL to "9.3" - the attributes
within the PostgreSQL cookbook that interpolate the version
attribute do not receive the attribute override.
Two notes:
- I am able to set the postgresql version attribute to the
desired "9.3" in my .kitchen.yml file and the override works
as you would expect/hope it would. Meaning, all string
interpolated attributes in the postgresql cookbook receive
"9.3" as its version.
- After going through and overriding all attributes within
the PostgreSQL cookbook that use string interpolation, I ran
into one last snag that has stopped me from completing the
cookbook. There are two attributes within the PostgreSQL
cookbook that set the "unix_socket_directory[-ies]" attribute
based on the PostgreSQL version. However, since the logic is
broken up into two separate lines, and the string
interpolation doesn't pick up the correct version, it will
actually add both attributes to the postgresql.conf template
- breaking the service.
Lines 166-167
https://github.com/hw-cookbooks/postgresql/blob/master/attributes/default.rb#L166
I appreciate any input, thanks!
Bill Young
Yeah you can do that. You have to use default attrs in your library
cookbook and override attrs in all wrapper/role/etc cookbooks, then you
roll-your-own include_attributes to run in the recipe code of your
wrapper/role cookbook and slurp those in as early as possible. You have to
use override attrs or else when you load the library cookbooks attr file
you'll overwrite everything again. Generally we think that solution has
considerable code smell and isn't going to scale, and is going down the
path that has led us to force_override/force_default and other hacks added
to Chef to get people out of painting themselves into a corner. The best
practice is generally not to be setting attributes in recipe code and to
move attribute setting into attribute files in order to get away from
compile/converge issues in recipe code. In simple cases, though, that does
work.
On 1/13/14 6:04 PM, Greg Zapp wrote:
Hi,
Sorry for the short reply. Correct me if I'm wrong, but looking at the
source code, when you get a attribute key it returns the merged_attributes
key? So, if you were to override version and then use attribute_resolve to
re-load the attributes file on this line:
default['postgresql']['server']['packages'] = ["postgresql-#{node['
postgresql']['version']}"]
It should get the overridden key for "node['postgresql']['version'] and
work as expected?
I am writing a wrapper cookbook for the community postgresqlhttps://github.com/hw-cookbooks/postgresql cookbook.
Essentially, what I'm trying to do is override the following attributes:
When setting an override attribute in my wrapper cookbook to set the
version of PostgreSQL to "9.3" - the attributes within the PostgreSQL
cookbook that interpolate the version attribute do not receive the
attribute override.
Two notes:
I am able to set the postgresql version attribute to the desired
"9.3" in my .kitchen.yml file and the override works as you would
expect/hope it would. Meaning, all string interpolated attributes in the
postgresql cookbook receive "9.3" as its version.
After going through and overriding all attributes within the
PostgreSQL cookbook that use string interpolation, I ran into one last snag
that has stopped me from completing the cookbook. There are two attributes
within the PostgreSQL cookbook that set the "unix_socket_directory[-ies]"
attribute based on the PostgreSQL version. However, since the logic is
broken up into two separate lines, and the string interpolation doesn't
pick up the correct version, it will actually add both attributes to the
postgresql.conf template - breaking the service.
Not sure if I'm missing something about your approach, but that is what
I'm talking about doing -- although that example code is converge-mode
and I think its probably better to run it compile-time, as soon as possible.
On 1/14/14 10:24 PM, Torben Knerr wrote:
What about reloading the attributes rather than repeating the computed
one?
Yeah you can do that. You have to use default attrs in your
library cookbook and override attrs in all wrapper/role/etc
cookbooks, then you roll-your-own include_attributes to run in the
recipe code of your wrapper/role cookbook and slurp those in as
early as possible. You have to use override attrs or else when
you load the library cookbooks attr file you'll overwrite
everything again. Generally we think that solution has
considerable code smell and isn't going to scale, and is going
down the path that has led us to force_override/force_default and
other hacks added to Chef to get people out of painting themselves
into a corner. The best practice is generally not to be setting
attributes in recipe code and to move attribute setting into
attribute files in order to get away from compile/converge issues
in recipe code. In simple cases, though, that does work.
On 1/13/14 6:04 PM, Greg Zapp wrote:
Hi,
Sorry for the short reply. Correct me if I'm wrong, but looking
at the source code, when you get a attribute key it returns the
merged_attributes key? So, if you were to override version and
then use attribute_resolve to re-load the attributes file on this
line:
default['postgresql']['server']['packages'] =
["postgresql-#{node['postgresql']['version']}"]
It should get the overridden key for
"node['postgresql']['version'] and work as expected?
-Greg
On Tue, Jan 14, 2014 at 2:51 PM, Greg Zapp <greg.zapp@gmail.com
<mailto:greg.zapp@gmail.com>> wrote:
You can re-load the attributes file from your recipe.
On Tue, Jan 14, 2014 at 2:01 PM, Lamont Granquist
<lamont@opscode.com <mailto:lamont@opscode.com>> wrote:
wrapper/role cookbooks don't work with those. either you
need to use roles, or you need to override all the
computed attributes in the cookbook.
see: https://tickets.opscode.com/browse/CHEF-4837
On 1/13/14 12:02 PM, Bill Young wrote:
Hello All,
I am writing a wrapper cookbook for the community
postgresql
<https://github.com/hw-cookbooks/postgresql> cookbook.
Essentially, what I'm trying to do is override the
following attributes:
default['postgresql']['enable_pgdg_apt'] = false
default['postgresql']['version'] = "9.1"
However, many of the attributes within the community
postgresql cookbook use string interpolation for the
version. Example:
default['postgresql']['server']['packages'] =
["postgresql-#{node['postgresql']['version']}"]
When setting an override attribute in my wrapper
cookbook to set the version of PostgreSQL to "9.3" - the
attributes within the PostgreSQL cookbook that
interpolate the version attribute do not receive the
attribute override.
Two notes:
- I am able to set the postgresql version attribute to
the desired "9.3" in my .kitchen.yml file and the
override works as you would expect/hope it would.
Meaning, all string interpolated attributes in the
postgresql cookbook receive "9.3" as its version.
- After going through and overriding all attributes
within the PostgreSQL cookbook that use string
interpolation, I ran into one last snag that has stopped
me from completing the cookbook. There are two
attributes within the PostgreSQL cookbook that set the
"unix_socket_directory[-ies]" attribute based on the
PostgreSQL version. However, since the logic is broken
up into two separate lines, and the string interpolation
doesn't pick up the correct version, it will actually
add both attributes to the postgresql.conf template -
breaking the service.
Lines 166-167
https://github.com/hw-cookbooks/postgresql/blob/master/attributes/default.rb#L166
I appreciate any input, thanks!
Bill Young
Just wanted to add the link to the docs showing the code how to reload
attributes.
+1 for compile time, not sure why the docs explictly show the converge time
example. It should show both options imho.
On Jan 17, 2014 8:29 PM, "Lamont Granquist" lamont@opscode.com wrote:
Not sure if I'm missing something about your approach, but that is what
I'm talking about doing -- although that example code is converge-mode and
I think its probably better to run it compile-time, as soon as possible.
On 1/14/14 10:24 PM, Torben Knerr wrote:
What about reloading the attributes rather than repeating the computed one?
Yeah you can do that. You have to use default attrs in your library
cookbook and override attrs in all wrapper/role/etc cookbooks, then you
roll-your-own include_attributes to run in the recipe code of your
wrapper/role cookbook and slurp those in as early as possible. You have to
use override attrs or else when you load the library cookbooks attr file
you'll overwrite everything again. Generally we think that solution has
considerable code smell and isn't going to scale, and is going down the
path that has led us to force_override/force_default and other hacks added
to Chef to get people out of painting themselves into a corner. The best
practice is generally not to be setting attributes in recipe code and to
move attribute setting into attribute files in order to get away from
compile/converge issues in recipe code. In simple cases, though, that does
work.
On 1/13/14 6:04 PM, Greg Zapp wrote:
Hi,
Sorry for the short reply. Correct me if I'm wrong, but looking at the
source code, when you get a attribute key it returns the merged_attributes
key? So, if you were to override version and then use attribute_resolve to
re-load the attributes file on this line:
default['postgresql']['server']['packages'] = ["postgresql-#{node['
postgresql']['version']}"]
It should get the overridden key for "node['postgresql']['version'] and
work as expected?
I am writing a wrapper cookbook for the community postgresqlhttps://github.com/hw-cookbooks/postgresql cookbook.
Essentially, what I'm trying to do is override the following attributes:
When setting an override attribute in my wrapper cookbook to set the
version of PostgreSQL to "9.3" - the attributes within the PostgreSQL
cookbook that interpolate the version attribute do not receive the
attribute override.
Two notes:
I am able to set the postgresql version attribute to the desired
"9.3" in my .kitchen.yml file and the override works as you would
expect/hope it would. Meaning, all string interpolated attributes in the
postgresql cookbook receive "9.3" as its version.
After going through and overriding all attributes within the
PostgreSQL cookbook that use string interpolation, I ran into one last snag
that has stopped me from completing the cookbook. There are two attributes
within the PostgreSQL cookbook that set the "unix_socket_directory[-ies]"
attribute based on the PostgreSQL version. However, since the logic is
broken up into two separate lines, and the string interpolation doesn't
pick up the correct version, it will actually add both attributes to the
postgresql.conf template - breaking the service.