[chef] Re: Re: strange node attribute problem

[John Alberts < >]

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 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 < " target="_blank"> > 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 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 < " target="_blank"> > 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: 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