[chef] RE: Re: Re: recipe_name converted to empty list

[Martin Smith < >]

For what it's worth, while definitions might be evil, I found the same thing 
happening on an LWRP after the chef 12 release; I don't think this is 
isolated to definitions, if it's the same issue:

https://github.com/opscode-cookbooks/openssl/issues/10

- Martin

________________________________________
From: Noah Kantrowitz 

 
Sent: Tuesday, December 09, 2014 2:13 PM
To: 

 
Subject: [chef] Re: Re: recipe_name converted to empty list

On Dec 9, 2014, at 12:04 PM, John de la Garza 
<
 >
 wrote:

> On Tue, Dec 9, 2014 at 2:37 PM, John de la Garza
> <
 >
>  wrote:
>> when I run the following recipe I get this output:
>>
>> ==> zs1: [2014-12-09T19:35:15+00:00] ERROR: hey john
>> ==> zs1: [2014-12-09T19:35:15+00:00] ERROR: hey []
>>
>> why is recipe_name altered inside the logrotate_app block?  The
>> resulting config files
>> have [] in the place where I would expect the recipe name.
>>
>>
>> ---recipe---
>> Chef::Log.error("hey #{recipe_name}")
>> logrotate_app recipe_name do
>>  Chef::Log.error("hey #{recipe_name}")
>>  cookbook  'logrotate'
>>  path %W|/var/log/careverge/#{recipe_name}.console
>> /var/log/careverge/#{recipe_name}.json|
>>  frequency 'daily'
>>  rotate 2
>>  size '100M'
>>  options %w|copytruncate compress nodelaycompress missingok|
>> end
>
> ok, I think I understand why I get this behavior
>
> logrotate_app is a definition so it gets handled before recipe_name is 
> available
>
> can someone confirm if my understanding is correct

No, the issue is that the block for definitions are evaluated in a weird 
context. Just assign the value to a variable outside the block so it can be a 
normal closure instead

r = recipe_name
logrotate_app do
   ...
   path "/foo/#{r}"
end

Alternatively stop using definitions because they are eeeeevil :-)

--Noah