[chef] Re: Re: Using the wrapper cookbook development method to remove the pager duty contact from the Nagios Cookbook


Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Subject: [chef] Re: Re: Using the wrapper cookbook development method to remove the pager duty contact from the Nagios Cookbook
  • Date: Mon, 18 May 2015 10:29:21 -0700



On Monday, May 18, 2015 at 9:25 AM, Joseph Hammerman wrote:

> Hi Chef users email distribution list,
>  
> An update on this item: if I set load\_default\_config to false my template 
> renders correctly. Therefore, I conclude that the observed behavior is a 
> consequence of Chef’s resource cloning.  
>  
> The only change from the pastebin below is that I tried defining and 
> explicitly passing in the variable that I have manipulated in my wrapper 
> logic:  
>  
> nagios_contactgroups = Nagios.instance.contactgroups  
>  
> begin  
> t = resources(:template => "#{node['nagios']['config_dir']}/contacts.cfg")
> t.source "contacts.cfg.erb"
> t.cookbook "sm-nagios"
> t.variables(:nagios_contactgroups => Nagios.instance.contactgroups)
> #rescue Chef::Exceptions::ResourceNotFound
> # Chef::Log.warn "could not find template 
> #{node['nagios']['config_dir']/contacts.cfg to modify"
> End
>  
>  
> Can anyone shed light on why the cloned resource is superseding my attempt 
> to open back up the object and re-render it?
The problem with the clone behavior (well, one of them) is that you end up 
with two resources of the same type+name, but Chef elsewhere treats type+name 
as a unique id for a resource in the collection. Therefore, anything that 
looks up a resource by name+type (like the `resources` method) is going to 
have undefined behavior when resources have been cloned.

--  
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§