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

[Martin N Stevens < >]

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.