# Strange node attribute problem

**URL:** <https://discourse.chef.io/t/strange-node-attribute-problem/3996>\
**Category:** Chef Infra (archive)\
**Created:** [May 23, 2013, 5:02am UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996 "2013-05-23T05:02:26Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Alberts](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_alberts/32/293_2.png) [@John\_Alberts](https://discourse.chef.io/u/John_Alberts)\
**Post date:** [May 23, 2013, 5:02am UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996/1 "2013-05-23T05:02:26Z")

</div>

I have a strange problem with using a node attribute that recently had the  
value changed.  
I have a ruby\_block resource that sets a node attribute. The following  
mount resource uses that node attribute, but it is getting the old value of  
that node attribute, not the new value that was just set by the previous  
ruby\_block. I’ve tried adding a node.save in that ruby\_block, but the  
mount resource still gets the old attribute value. Of course, since I did  
a node.save, the mount resource gets the new value because it was save on  
the previous failed chef run.  
Is this expected behavior? I’ve never noticed this before.

Here is the section of code I’m having the issue with. It’s the  
node[:ebs][:devicetomount] attribute that I’m having trouble with.

Original pastebin here: [http://pastebin.com/XmQ2KtBn](http://pastebin.com/XmQ2KtBn)

Thanks  
John

1. ruby\_block “Create or attach LVM volume out of #{raid\_device}” do
2. 

```
block do

```

3. 

```
  BlockDevice.create_lvm(raid_device, options)

```

4. 

```
  node.set[:ebs][:devicetomount] = node[:ebs][:lvm_device]

```

5. 

```
  node.save unless Chef::Config[:solo]

```

6. 

```
end

```

7. 

```
only_if { options[:uselvm] }

```

8. 

```
action :create

```

9. end
10. 
11. mount options[:mount\_point] do
12. 

```
fstype options[:fstype]

```

13. 

```
device node[:ebs][:devicetomount]

```

14. 

```
options "noatime"

```

15. 

```
not_if do

```

16. 

```
  File.read('/etc/mtab').split("\n").any?{|line| line.match("

```

#{options[:mount\_point]} ")}  
17. end  
18. end

---

<div class="post-metadata">

**Author:** ![Kannan\_Manickam1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kannan_manickam1/32/522_2.png) [@Kannan\_Manickam1](https://discourse.chef.io/u/Kannan_Manickam1)\
**Post date:** [May 23, 2013, 7:48am UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996/2 "2013-05-23T07:48:03Z")

</div>

John,

Yes, that is the expected behavior. The block inside the ruby block gets  
executed during the converge phase where as the attributes for the mount  
resources gets set during the compile phase. So even though the the mount  
resource's action gets executed during the converge phase the value of the  
attributes for that resource will not get updated after the ruby block's  
execution.

You have three possible solutions here:

1. Change the ruby\_block to get executed during compile time if that will  
work for you.
2. Change the logic of mount to be executed as ruby code inside the  
ruby\_block itself.
3. Few days ago, I was playing with a hack to dynamically setting  
attributes of resources [Dynamically update attribute of a Chef resource during converge phase (Node variable assignment in Compile vs Converge) · GitHub](https://gist.github.com/arangamani/4659646) - It is  
not a cleaner way but a working solution.

I would be glad to know if there are other solutions.

Cheers,  
Kannan.

On Thu, May 23, 2013 at 10:32 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> I have a strange problem with using a node attribute that recently had the  
> value changed.  
> I have a ruby\_block resource that sets a node attribute. The following  
> mount resource uses that node attribute, but it is getting the old value of  
> that node attribute, not the new value that was just set by the previous  
> ruby\_block. I've tried adding a node.save in that ruby\_block, but the  
> mount resource still gets the old attribute value. Of course, since I did  
> a node.save, the mount resource gets the new value because it was save on  
> the previous failed chef run.  
> Is this expected behavior? I've never noticed this before.
> 
> Here is the section of code I'm having the issue with. It's the  
> node[:ebs][:devicetomount] attribute that I'm having trouble with.
> 
> Original pastebin here: [chef node attribute, wtf? - Pastebin.com](http://pastebin.com/XmQ2KtBn)
> 
> Thanks  
> John
> 
> 1. ruby\_block "Create or attach LVM volume out of #{raid\_device}" do
> 2. 
> 
> ```
> block do
> 
> ```
> 
> 3. 
> 
> ```
> BlockDevice.create_lvm(raid_device, options)
> 
> ```
> 
> 4. 
> 
> ```
> node.set[:ebs][:devicetomount] = node[:ebs][:lvm_device]
> 
> ```
> 
> 5. 
> 
> ```
> node.save unless Chef::Config[:solo]
> 
> ```
> 
> 6. 
> 
> ```
> end
> 
> ```
> 
> 7. 
> 
> ```
> only_if { options[:uselvm] }
> 
> ```
> 
> 8. 
> 
> ```
> action :create
> 
> ```
> 
> 9. end
> 10. 
> 11. mount options[:mount\_point] do
> 12. 
> 
> ```
> fstype options[:fstype]
> 
> ```
> 
> 13. 
> 
> ```
> device node[:ebs][:devicetomount]
> 
> ```
> 
> 14. 
> 
> ```
> options "noatime"
> 
> ```
> 
> 15. 
> 
> ```
> not_if do
> 
> ```
> 
> 16. 
> 
> ```
> File.read('/etc/mtab').split("\n").any?{|line| line.match("
> 
> ```
> 
> #{options[:mount\_point]} ")}  
> 17. end  
> 18. end

---

<div class="post-metadata">

**Author:** ![John\_Alberts](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_alberts/32/293_2.png) [@John\_Alberts](https://discourse.chef.io/u/John_Alberts)\
**Post date:** [May 23, 2013, 2:51pm UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996/3 "2013-05-23T14:51:46Z")

</div>

I was considering resorting to saving the value to a file as well, but I  
was hoping/praying for a better method than that. I chatted with someone  
on #Chef Infra (archive) last night and he suggested using a helper method in a library  
that just returned the node attribute. I gave this a try, but it didn't  
fix the problem. It still returns the old value of the attribute and not  
the current value. I'm assuming the library method is also called during  
the compile phase, which is why I'm still getting the value of the  
attribute before it was changed by a resource.

Anyone else have any suggestions before we resort to saving values in files  
so they can be changed and used during a Chef run?

Thanks  
John

On Thu, May 23, 2013 at 2:48 AM, Kannan Manickam [kannan@rightscale.com](mailto:kannan@rightscale.com)wrote:

> John,
> 
> Yes, that is the expected behavior. The block inside the ruby block gets  
> executed during the converge phase where as the attributes for the mount  
> resources gets set during the compile phase. So even though the the mount  
> resource's action gets executed during the converge phase the value of the  
> attributes for that resource will not get updated after the ruby block's  
> execution.
> 
> You have three possible solutions here:
> 
> 1. Change the ruby\_block to get executed during compile time if that will  
> work for you.
> 2. Change the logic of mount to be executed as ruby code inside the  
> ruby\_block itself.
> 3. Few days ago, I was playing with a hack to dynamically setting  
> attributes of resources [Dynamically update attribute of a Chef resource during converge phase (Node variable assignment in Compile vs Converge) · GitHub](https://gist.github.com/arangamani/4659646) - It  
> is not a cleaner way but a working solution.
> 
> I would be glad to know if there are other solutions.
> 
> Cheers,  
> Kannan.
> 
> On Thu, May 23, 2013 at 10:32 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:
> 
> > I have a strange problem with using a node attribute that recently had  
> > the value changed.  
> > I have a ruby\_block resource that sets a node attribute. The following  
> > mount resource uses that node attribute, but it is getting the old value of  
> > that node attribute, not the new value that was just set by the previous  
> > ruby\_block. I've tried adding a node.save in that ruby\_block, but the  
> > mount resource still gets the old attribute value. Of course, since I did  
> > a node.save, the mount resource gets the new value because it was save on  
> > the previous failed chef run.  
> > Is this expected behavior? I've never noticed this before.
> > 
> > Here is the section of code I'm having the issue with. It's the  
> > node[:ebs][:devicetomount] attribute that I'm having trouble with.
> > 
> > Original pastebin here: [chef node attribute, wtf? - Pastebin.com](http://pastebin.com/XmQ2KtBn)
> > 
> > Thanks  
> > John
> > 
> > 1. ruby\_block "Create or attach LVM volume out of #{raid\_device}" do
> > 2. 
> > 
> > ```
> > block do
> > 
> > ```
> > 
> > 3. 
> > 
> > ```
> > BlockDevice.create_lvm(raid_device, options)
> > 
> > ```
> > 
> > 4. 
> > 
> > ```
> > node.set[:ebs][:devicetomount] = node[:ebs][:lvm_device]
> > 
> > ```
> > 
> > 5. 
> > 
> > ```
> > node.save unless Chef::Config[:solo]
> > 
> > ```
> > 
> > 6. 
> > 
> > ```
> > end
> > 
> > ```
> > 
> > 7. 
> > 
> > ```
> > only_if { options[:uselvm] }
> > 
> > ```
> > 
> > 8. 
> > 
> > ```
> > action :create
> > 
> > ```
> > 
> > 9. end
> > 10. 
> > 11. mount options[:mount\_point] do
> > 12. 
> > 
> > ```
> > fstype options[:fstype]
> > 
> > ```
> > 
> > 13. 
> > 
> > ```
> > device node[:ebs][:devicetomount]
> > 
> > ```
> > 
> > 14. 
> > 
> > ```
> > options "noatime"
> > 
> > ```
> > 
> > 15. 
> > 
> > ```
> > not_if do
> > 
> > ```
> > 
> > 16. 
> > 
> > ```
> > File.read('/etc/mtab').split("\n").any?{|line| line.match("
> > 
> > ```
> > 
> > #{options[:mount\_point]} ")}  
> > 17. end  
> > 18. end

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [May 23, 2013, 3:11pm UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996/4 "2013-05-23T15:11:47Z")

</div>

On Thursday, May 23, 2013 at 12:48 AM, Kannan Manickam wrote:

> John,
> 
> Yes, that is the expected behavior. The block inside the ruby block gets executed during the converge phase where as the attributes for the mount resources gets set during the compile phase. So even though the the mount resource's action gets executed during the converge phase the value of the attributes for that resource will not get updated after the ruby block's execution.
> 
> You have three possible solutions here:
> 
> 1. Change the ruby\_block to get executed during compile time if that will work for you.
> 2. Change the logic of mount to be executed as ruby code inside the ruby\_block itself.
> 3. Few days ago, I was playing with a hack to dynamically setting attributes of resources [Dynamically update attribute of a Chef resource during converge phase (Node variable assignment in Compile vs Converge) · GitHub](https://gist.github.com/arangamani/4659646) - It is not a cleaner way but a working solution.
> 
> I would be glad to know if there are other solutions.
> 
> Cheers,  
> Kannan.

Chef 11.6 will have a lazy attribute feature that would handle this pretty easily:

[http://tickets.opscode.com/browse/CHEF-3731](http://tickets.opscode.com/browse/CHEF-3731)

--  
Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![John\_Alberts](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_alberts/32/293_2.png) [@John\_Alberts](https://discourse.chef.io/u/John_Alberts)\
**Post date:** [May 23, 2013, 3:35pm UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996/5 "2013-05-23T15:35:44Z")

</div>

On Thu, May 23, 2013 at 10:11 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> Chef 11.6 will have a lazy attribute feature that would handle this pretty  
> easily:
> 
> [http://tickets.opscode.com/browse/CHEF-3731](http://tickets.opscode.com/browse/CHEF-3731)

Thanks for pointing this out. Yet another reason for me to find time to  
push forward and upgrade from 10.x to 11.x. 🙂

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![John\_Alberts](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_alberts/32/293_2.png) [@John\_Alberts](https://discourse.chef.io/u/John_Alberts)\
**Post date:** [May 23, 2013, 5:33pm UTC](https://discourse.chef.io/t/strange-node-attribute-problem/3996/6 "2013-05-23T17:33:56Z")

</div>

I just wanted to update the list to say that I tried the delayed\_evaluator  
cookbook and it worked perfectly. Hooray!

John

On Thu, May 23, 2013 at 10:35 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> On Thu, May 23, 2013 at 10:11 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> 
> > Chef 11.6 will have a lazy attribute feature that would handle this  
> > pretty easily:
> > 
> > [http://tickets.opscode.com/browse/CHEF-3731](http://tickets.opscode.com/browse/CHEF-3731)
> 
> Thanks for pointing this out. Yet another reason for me to find time to  
> push forward and upgrade from 10.x to 11.x. 🙂
> 
> --  
> John Alberts

--  
John Alberts