Strange node attribute problem

John_Alberts · May 23, 2013, 5:02am

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

Thanks
John

ruby_block “Create or attach LVM volume out of #{raid_device}” do
```
block do
```

  BlockDevice.create_lvm(raid_device, options)

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

```
  node.save unless Chef::Config[:solo]
```
```
end
```
```
only_if { options[:uselvm] }
```
```
action :create
```
end
mount options[:mount_point] do
```
fstype options[:fstype]
```
```
device node[:ebs][:devicetomount]
```
```
options "noatime"
```
```
not_if do
```

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

#{options[:mount_point]} ")}
17. end
18. end

Kannan_Manickam1 · May 23, 2013, 7:48am

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:

Change the ruby_block to get executed during compile time if that will
work for you.
Change the logic of mount to be executed as ruby code inside the
ruby_block itself.
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 - 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.comwrote:

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

Thanks
John
ruby_block "Create or attach LVM volume out of #{raid_device}" do
block do
  BlockDevice.create_lvm(raid_device, options)
  node.set[:ebs][:devicetomount] = node[:ebs][:lvm_device]
  node.save unless Chef::Config[:solo]
end
only_if { options[:uselvm] }
action :create
end

mount options[:mount_point] do
fstype options[:fstype]
device node[:ebs][:devicetomount]
options "noatime"
not_if do
  File.read('/etc/mtab').split("\n").any?{|line| line.match("
#{options[:mount_point]} ")}
17. end
18. end

John_Alberts · May 23, 2013, 2:51pm

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.comwrote:

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:

Change the ruby_block to get executed during compile time if that will
work for you.

Change the logic of mount to be executed as ruby code inside the
ruby_block itself.

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 - 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.comwrote:
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

Thanks
John
ruby_block "Create or attach LVM volume out of #{raid_device}" do
block do
  BlockDevice.create_lvm(raid_device, options)
  node.set[:ebs][:devicetomount] = node[:ebs][:lvm_device]
  node.save unless Chef::Config[:solo]
end
only_if { options[:uselvm] }
action :create
end

mount options[:mount_point] do
fstype options[:fstype]
device node[:ebs][:devicetomount]
options "noatime"
not_if do
  File.read('/etc/mtab').split("\n").any?{|line| line.match("
#{options[:mount_point]} ")}
17. end
18. end

--
John Alberts

kallistec · May 23, 2013, 3:11pm

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:

Change the ruby_block to get executed during compile time if that will work for you.

Change the logic of mount to be executed as ruby code inside the ruby_block itself.

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 - 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

--
Daniel DeLeo

John_Alberts · May 23, 2013, 3:35pm

On Thu, May 23, 2013 at 10:11 AM, Daniel DeLeo 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

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 · May 23, 2013, 5:33pm

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.comwrote:

On Thu, May 23, 2013 at 10:11 AM, Daniel DeLeo 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

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

Topic		Replies	Views
How to update node attribute in a 'ruby_block' Chef Infra (archive)	7	3694	June 25, 2018
Using attributes to pass information about resources between nodes Chef Infra (archive)	0	312	July 29, 2010
Setting a node attribute from chef_handler does not work for me Chef Infra (archive)	2	634	February 6, 2016
Node attributes ignored and defaults used only once. Pointers to debug Chef Infra (archive)	8	1321	October 16, 2016
ruby_block that sets/alters attributes Chef Infra (archive)	2	369	July 8, 2010

Strange node attribute problem

Related topics