Strange node attribute problem

Chef Infra (archive)
1

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

2

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

3

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

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

4

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

–
Daniel DeLeo

5

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

–
John Alberts

6

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

–
John Alberts

–
John Alberts