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.
[1] https://github.com/dcrosta/cookbook-simple-iptables/issues/5
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 dcrosta@late.am 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.
[1] simple_iptables_policy not working with chef-solo · Issue #5 · rtkwlf/cookbook-simple-iptables · GitHub
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.
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 dcrosta@late.am 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.
[1] simple_iptables_policy not working with chef-solo · Issue #5 · rtkwlf/cookbook-simple-iptables · GitHub