[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Wrapper cookbooks and attribute logic

[Lamont Granquist < >]

    The simplest way to deal with computed attributes is to move the
    logic entirely into the recipe and do *NOT* use an attribute.  Just
    use a plain old ruby variable.  Not everything needs to be an
    attribute. 
    
    Of course this normally means making a change to the 'upstream'
    cookbook that is doing the computed attribute which your wrapper
    cookbook is having issues with.

On 06/16/2015 10:28 AM, Torben Knerr wrote:

" type="cite">

Haven't tried it recently, but this helped me getting around with computed attributes in wrapper cookbooks once:

Namely you can force re-evaluation of the original attributes file in your wrapper cookbook (see http://docs.opscode.com/chef/essentials_cookbook_recipes.html#reload-attributes):

```
node.set['nfs']['something'] = 'foo'

# now re-evaluate the default attributes file from the nfs cookbook
node.from_file(run_context.resolve_attribute("nfs", "default.rb"))
```

HTH, Torben

Am 16.06.2015 16:54 schrieb "Yoshi Spendiff" < "> >:

Thanks Martin, I've seen that a few times actually.

In this case the attributes would be at the same precedence level, but Drew has said that because the dependency cookbooks are loaded first the wrapper cookbook overwrites the values even at the same precedence level. And that seems to be backed up in the 'Ordered Evaluation of Attributes Files' section of this page: https://www.chef.io/blog/2013/02/05/chef-11-in-depth-attributes-changes/

The cookbook I made changes to has depends 'nfs' in metadata and I'm redefining only default precedence level attributes from the attributes file in that cookbook, so in theory changing all of the wrapper cookbook attributes from set to default level should have effectively been no change, but that was not the case.

On Tue, Jun 16, 2015 at 7:19 AM, Martin N Stevens < " target="_blank"> > wrote:

Have a look at 

https://docs.chef.io/attributes.html

An find the attribute precidence table grpahic.... it makes it really clear.

On 16 June 2015 at 15:19, Martin Stevens < " target="_blank"> > wrote:

Have a look at 

https://docs.chef.io/attributes.html

An find the attribute precidence table grpahic.... it makes it really clear.

On 16 June 2015 at 15:17, Martin Stevens < " target="_blank"> > wrote:

Have a look at 

https://docs.chef.io/attributes.html

An find the attribute precidence table grpahic.... it makes it really clear.

On 16 June 2015 at 02:29, Yoshi Spendiff < " target="_blank"> > wrote:

Following on from what Drew said, as I guess this is a bit of a discussion on how wrapper cookbook attributes work:

I'm using the nfs cookbook on amazon linux and thus have to set the following attributes in my wrapper cookbook. This is what I had and the cookbook was working:

set['nfs']['service']['lock'] = 'nfslock'
set['nfs']['service']['server'] = 'nfs'
set['nfs']['service']['portmap'] = 'rpcbind'
set['nfs']['service']['idmap'] = 'rpcidmapd'
set['nfs']['service_provider']['lock'] = Chef::Provider::Service::Redhat
set['nfs']['service_provider']['portmap'] = Chef::Provider::Service::Redhat
set['nfs']['service_provider']['server'] = Chef::Provider::Service::Redhat

I changed the priority on all of these attributes from set to default and I get the following error:

  ================================================================================
  Recipe Compile Error in /var/chef/cache/cookbooks/indochino-role/recipes/web-server.rb
  ================================================================================
 
  NameError
  ---------
  uninitialized constant Chef_provider_service_redhat
 
  Cookbook Trace:
  ---------------
    /var/chef/cache/cookbooks/nfs/recipes/_common.rb:45:in `block (2 levels) in from_file'
    /var/chef/cache/cookbooks/nfs/recipes/_common.rb:43:in `block in from_file'
    /var/chef/cache/cookbooks/nfs/recipes/_common.rb:42:in `each'
    /var/chef/cache/cookbooks/nfs/recipes/_common.rb:42:in `from_file'
    /var/chef/cache/cookbooks/nfs/recipes/client4.rb:22:in `block in from_file'
    /var/chef/cache/cookbooks/nfs/recipes/client4.rb:21:in `each'
    /var/chef/cache/cookbooks/nfs/recipes/client4.rb:21:in `from_file'
    /var/chef/cache/cookbooks/indochino-role/recipes/web-server.rb:16:in `from_file'
 
  Relevant File Content:
  ----------------------
  /var/chef/cache/cookbooks/nfs/recipes/_common.rb:
 
   38:    end
   39:  end
   40: 
   41:  # Start NFS client components
   42:  %w(portmap lock).each do |component|
   43:    service component do
   44:      service_name node['nfs']['service'][component]
   45>>     provider node['nfs']['service_provider'][component]
   46:      action [:start, :enable]
   47:      supports :status => true
   48:    end
   49:  end
   50: 

The base nfs cookbook ascertains the provider using Chef::Platform.find_provider_for_node node, :service, which if I run on the node in chef-shell I get the following:
chef > Chef::Platform.find_provider_for_node node, :service
 => Chef::Provider::Service::Redhat

So the same as what I hard set.

So what's going on here? O.o

On Mon, Jun 15, 2015 at 1:00 PM, Yoshi Spendiff < " target="_blank"> > wrote:

Huh, so they do (from Chef 11+ I guess it's worth mentioning). I thought the alphabetical list was for all attribute files but it's per cookbook.

Time to rejig a few things then...

On Mon, Jun 15, 2015 at 12:42 PM, Drew Blessing < " target="_blank"> > wrote:

Yoshi,

Wrapper cookbooks do not necessarily need to use a higher precedence level because of load order. If a wrapper cookbook depends on a 'dependent' cookbook the dependent cookbook's attributes are loaded first, and then the wrapper cookbook. This effectively overrides the dependent cookbook's default attributes without using a higher precedence level. Note that a higher precedence level in the dependent cookbook *will* override a wrapper's default level attribute, though. 

On Mon, Jun 15, 2015 at 1:55 PM, Bryan Baugher < " target="_blank"> > wrote:

Wow thats exactly my problem[1] thanks!

[1] - https://coderanger.net/derived-attributes/

On Mon, Jun 15, 2015 at 1:41 PM Yoshi Spendiff < " target="_blank"> > wrote:

Also, when you say 'default' are you meaning default priority?

i.e. default['cookbook']['attribute'] = 'thing'?

Cause if you are trying to override a base cookbook you will need to use a priority level above default in your wrapper attributes,

i.e. set['cookbook']['attribute'] = 'override thing'

On Mon, Jun 15, 2015 at 11:13 AM, Kenneth Barry < " target="_blank"> > wrote:

I "Think" this may be atleast part of what yur dealing with.

https://coderanger.net/derived-attributes/

On Mon, Jun 15, 2015 at 11:05 AM, Bryan Baugher < " target="_blank"> > wrote:

Hi everyone,

We have recently started using wrapper cookbooks which generally just set some default attributes. We are running into issues where cookbooks we are consuming are attempting to do some kind of logic in their attributes file based on these attribute values. We run into problems when these cookbooks load their attribute files first before our wrapper cookbooks can apply their defaults.

Has anyone run into this problem? Any ideas?

--

Kenneth Barry 

TuneIn | Build and Release Engineer

M: 409-673-0544

www.tunein.com

--

Yoshi Spendiff

Ops Engineer

Indochino

Mobile: +1 778 952 2025

Email: " target="_blank">

--

Drew

--

Yoshi Spendiff

Ops Engineer

Indochino

Mobile: +1 778 952 2025

Email: " target="_blank">

--

Yoshi Spendiff

Ops Engineer

Indochino

Mobile: +1 778 952 2025

Email: " target="_blank">

--

Work: 01992 703382 - Mobile: 07815 982380
Think Green - don't print this email unless you really need to.

--

Work: 01992 703382 - Mobile: 07815 982380
Think Green - don't print this email unless you really need to.

--

Work: 01992 703382 - Mobile: 07815 982380
Think Green - don't print this email unless you really need to.

--

Yoshi Spendiff

Ops Engineer

Indochino

Mobile: +1 778 952 2025

Email: " target="_blank">