[chef] Re: Re: Does chef-solo treat node.set differently than chef-client?

[Dan Crosta < >]

Chef-solo definitely doesn't persist the node data after each run, which I 
suspect is the issue you're running into here. Cookbooks like aws which 
expect Chef to do so probably won't work correctly with chef-solo.

- Dan

On Aug 18, 2012, at 9:04 AM, Hector Castro wrote:

> I haven't dug into this yet, but I recently saw slightly similar
> behavior with `node.set` on a Chef Server setup within the AWS
> cookbook (Chef 10.12).  It doesn't look like the EBS LWRP is
> persisting newly created volume ID references in node attributes.
> 
> I'll probably be looking into this a little closer early next week,
> but if anyone has seen this behavior and has details, please chime in.
> 
> --
> Hector
> 
> 
> On Sat, Aug 4, 2012 at 5:18 PM, Dan Crosta 
> <
 >
>  wrote:
>> A user reported a bug [1] against one of my cookbooks that has me stumped: 
>> one of my LWRPs accumulates state by setting node attributes using 
>> something like node.set["foo"]["bar"] = "baz". This state is later used in 
>> a template.
>> 
>> With chef-client, this works as expected -- the attribute is set and 
>> readable (as node["foo"]["bar"]) at the time the template is evaluated. 
>> With chef-solo, the attribute is set, and I can verify by .inspect'ing the 
>> attribute in a Chef::Log.debug message (it shows up under 
>> @current_normal); however, when the template renders, it is as though the 
>> attribute had never been set at all. More puzzling, if I change the 
>> node.set to a node.default, it works correctly.
>> 
>> I am completely baffled by this behavior -- is it expected? Is it a bug in 
>> chef-solo? Or a bug in my LWRP or recipe? Any help would be appreciated.
>> 
>> - Dan
>> 
>> 
>> [1] https://github.com/dcrosta/cookbook-simple-iptables/issues/5