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?
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 bjbq4d@gmail.com 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
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 kbarry@tunein.com wrote:
I "Think" this may be atleast part of what yur dealing with.
Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 11:05 AM, Bryan Baugher bjbq4d@gmail.com 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: yoshi.spendiff@indochino.com
Wow thats exactly my problem[1] thanks!
[1] - Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 1:41 PM Yoshi Spendiff yoshi.spendiff@indochino.com
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 kbarry@tunein.com wrote:
I "Think" this may be atleast part of what yur dealing with.
Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 11:05 AM, Bryan Baugher bjbq4d@gmail.com 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: yoshi.spendiff@indochino.com
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 bjbq4d@gmail.com wrote:
Wow thats exactly my problem[1] thanks!
[1] - Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 1:41 PM Yoshi Spendiff <
yoshi.spendiff@indochino.com> 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 kbarry@tunein.com
wrote:I "Think" this may be atleast part of what yur dealing with.
Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 11:05 AM, Bryan Baugher bjbq4d@gmail.com
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: yoshi.spendiff@indochino.com
--
Drew
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 drew@blessing.io 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 bjbq4d@gmail.com wrote:
Wow thats exactly my problem[1] thanks!
[1] - Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 1:41 PM Yoshi Spendiff <
yoshi.spendiff@indochino.com> 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 kbarry@tunein.com
wrote:I "Think" this may be atleast part of what yur dealing with.
Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 11:05 AM, Bryan Baugher bjbq4d@gmail.com
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: yoshi.spendiff@indochino.com--
Drew
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
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
================================================================================
uninitialized constant Chef_provider_service_redhat
/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'
/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 <
yoshi.spendiff@indochino.com> 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 drew@blessing.io 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 bjbq4d@gmail.com wrote:
Wow thats exactly my problem[1] thanks!
[1] - Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 1:41 PM Yoshi Spendiff <
yoshi.spendiff@indochino.com> 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 kbarry@tunein.com
wrote:I "Think" this may be atleast part of what yur dealing with.
Derived Attributes in Chef – Noah Kantrowitz
On Mon, Jun 15, 2015 at 11:05 AM, Bryan Baugher bjbq4d@gmail.com
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: yoshi.spendiff@indochino.com--
Drew--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com