[chef] Re: Re: Re: Re: Re: Re: Attribute overrides in wrapper cookbook


Chronological Thread 
  • From: Torben Knerr < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Attribute overrides in wrapper cookbook
  • Date: Fri, 17 Jan 2014 20:45:52 +0100

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" < "> > 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?

http://docs.opscode.com/chef/essentials_cookbook_recipes.html#reload-attributes

On Jan 14, 2014 8:18 PM, "Lamont Granquist" < " target="_blank"> > wrote:

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 < " target="_blank"> > wrote:
You can re-load the attributes file from your recipe.


On Tue, Jan 14, 2014 at 2:01 PM, Lamont Granquist < " target="_blank"> > 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 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


I appreciate any input, thanks!


Bill Young










Archive powered by MHonArc 2.6.16.

§