# Delayed evaluation?

**URL:** <https://discourse.chef.io/t/delayed-evaluation/4814>\
**Category:** Chef Infra (archive)\
**Created:** [December 17, 2013, 5:18am UTC](https://discourse.chef.io/t/delayed-evaluation/4814 "2013-12-17T05:18:30Z")\
**Posts on this page:** 20\
**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:** [December 17, 2013, 5:18am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/1 "2013-12-17T05:18:30Z")

</div>

This seems like such a simple problem and something that everyone should  
come across at one point or another.

Here’s a short snippet of code that illustrates the issue I’m having:

(1…2).each do |count|  
ruby\_block “ls /tmp” do  
block do  
node.set[‘test1’][‘lsdir’] = %x[ls /tmp]  
end  
end

file “/tmp/file#{count}.txt” do  
content node[‘test1’][‘lsdir’]  
end  
end

So, at the end of the run, both /tmp/file1.txt and /tmp/file2.txt are  
empty. I had hoped for /tmp/file2.txt to show that '/tmp/file1.txt now  
exists.

I know this is because the value of attributes are evaluated during the  
compile phase at the beginning of the chef run and at that time, the value  
of node[‘test1’][‘lsdir’] is nil. Also, this same issue arises when trying  
to use a variable instead of an attribute.

How can I get something like this to execute as I would have hoped? This  
has to be a common pattern; set an attribute, use it, modify the attribute,  
use the new value. I know there is the new ‘lazy’ delayed evaluator, but I  
can only get that to work when used in a value for a resource attribute.

Thanks

–  
John Alberts

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [December 17, 2013, 5:34am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/2 "2013-12-17T05:34:35Z")

</div>

value of content is getting evaluated at compile time. its an attributed  
value and determined soon as the resource is created. while you are setting  
the node attribute via a ruby block, which gets evaluated at the compile  
time. some of the options. Im not sure if both assigning, mutating and then  
using the attribute is common pattern (or a good pattern at all).

i think if you move the file resource inside a lwrp and then notify that  
resource, that might work. because in that case the file resource will be  
created inside the provider's action block (which is evaluated only during  
the execution phase), hence u'll have the node.foo.bar value as you  
expected. there are several other ways to do the same trick, but this is  
the cleanest i can think of ..  
cheers  
ranjib

On Mon, Dec 16, 2013 at 9:18 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> This seems like such a simple problem and something that everyone should  
> come across at one point or another.
> 
> Here's a short snippet of code that illustrates the issue I'm having:
> 
> (1..2).each do |count|  
> ruby\_block "ls /tmp" do  
> block do  
> node.set['test1']['lsdir'] = %x[ls /tmp]  
> end  
> end
> 
> file "/tmp/file#{count}.txt" do  
> content node['test1']['lsdir']  
> end  
> end
> 
> So, at the end of the run, both /tmp/file1.txt and /tmp/file2.txt are  
> empty. I had hoped for /tmp/file2.txt to show that '/tmp/file1.txt now  
> exists.
> 
> I know this is because the value of attributes are evaluated during the  
> compile phase at the beginning of the chef run and at that time, the value  
> of node['test1']['lsdir'] is nil. Also, this same issue arises when trying  
> to use a variable instead of an attribute.
> 
> How can I get something like this to execute as I would have hoped? This  
> has to be a common pattern; set an attribute, use it, modify the attribute,  
> use the new value. I know there is the new 'lazy' delayed evaluator, but I  
> can only get that to work when used in a value for a resource attribute.
> 
> Thanks
> 
> --  
> John Alberts

---

<div class="post-metadata">

**Author:** ![coderanger](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/coderanger/32/5_2.png) [@coderanger](https://discourse.chef.io/u/coderanger)\
**Post date:** [December 17, 2013, 5:39am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/3 "2013-12-17T05:39:09Z")

</div>

The more generic solution is to use resources/LWRPs such that the second resource isn't compiled until after the settings you care about. For example [https://github.com/balanced-cookbooks/ci/blob/master/libraries/ci\_server.rb#L45-L46](https://github.com/balanced-cookbooks/ci/blob/master/libraries/ci_server.rb#L45-L46)

--Noah

On Dec 16, 2013, at 9:18 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com) wrote:

> This seems like such a simple problem and something that everyone should come across at one point or another.
> 
> Here's a short snippet of code that illustrates the issue I'm having:
> 
> (1..2).each do |count|  
> ruby\_block "ls /tmp" do  
> block do  
> node.set['test1']['lsdir'] = %x[ls /tmp]  
> end  
> end
> 
> file "/tmp/file#{count}.txt" do  
> content node['test1']['lsdir']  
> end  
> end
> 
> So, at the end of the run, both /tmp/file1.txt and /tmp/file2.txt are empty. I had hoped for /tmp/file2.txt to show that '/tmp/file1.txt now exists.
> 
> I know this is because the value of attributes are evaluated during the compile phase at the beginning of the chef run and at that time, the value of node['test1']['lsdir'] is nil. Also, this same issue arises when trying to use a variable instead of an attribute.
> 
> How can I get something like this to execute as I would have hoped? This has to be a common pattern; set an attribute, use it, modify the attribute, use the new value. I know there is the new 'lazy' delayed evaluator, but I can only get that to work when used in a value for a resource attribute.
> 
> Thanks
> 
> --  
> John Alberts

---

<div class="post-metadata">

**Author:** ![Torben\_Knerr](https://avatars.discourse-cdn.com/v4/letter/t/ba8739/32.png) [@Torben\_Knerr](https://discourse.chef.io/u/Torben_Knerr)\
**Post date:** [December 17, 2013, 8:21am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/4 "2013-12-17T08:21:40Z")

</div>

Another possible caveat:

Shouldn't it be 'ruby\_block "ls /tmp #{count}" do' ?

-Torben  
On Dec 17, 2013 6:39 AM, "Noah Kantrowitz" [noah@coderanger.net](mailto:noah@coderanger.net) wrote:

> The more generic solution is to use resources/LWRPs such that the second  
> resource isn't compiled until after the settings you care about. For  
> example  
> [https://github.com/balanced-cookbooks/ci/blob/master/libraries/ci\_server.rb#L45-L46](https://github.com/balanced-cookbooks/ci/blob/master/libraries/ci_server.rb#L45-L46)
> 
> --Noah
> 
> On Dec 16, 2013, at 9:18 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)  
> wrote:
> 
> > This seems like such a simple problem and something that everyone should  
> > come across at one point or another.
> > 
> > Here's a short snippet of code that illustrates the issue I'm having:
> > 
> > (1..2).each do |count|  
> > ruby\_block "ls /tmp" do  
> > block do  
> > node.set['test1']['lsdir'] = %x[ls /tmp]  
> > end  
> > end
> > 
> > file "/tmp/file#{count}.txt" do  
> > content node['test1']['lsdir']  
> > end  
> > end
> > 
> > So, at the end of the run, both /tmp/file1.txt and /tmp/file2.txt are  
> > empty. I had hoped for /tmp/file2.txt to show that '/tmp/file1.txt now  
> > exists.
> > 
> > I know this is because the value of attributes are evaluated during the  
> > compile phase at the beginning of the chef run and at that time, the value  
> > of node['test1']['lsdir'] is nil. Also, this same issue arises when trying  
> > to use a variable instead of an attribute.
> > 
> > How can I get something like this to execute as I would have hoped?  
> > This has to be a common pattern; set an attribute, use it, modify the  
> > attribute, use the new value. I know there is the new 'lazy' delayed  
> > evaluator, but I can only get that to work when used in a value for a  
> > resource attribute.
> > 
> > Thanks
> > 
> > --  
> > 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:** [December 17, 2013, 4:50pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/5 "2013-12-17T16:50:43Z")

</div>

Thanks everyone for the responses. So... it seems the consensus is that  
this is best done in a LWRP. I had considered doing that, it just seemed  
like overkill for what should be a simple operation; that being, change the  
value of a variable(or attribute) and use that variable again later in the  
code.

@Torben, Yes, I would probably get warnings for reusing a resource if I  
didn't give it a unique name in the loop, but that would be the extent of  
the impact.

John

On Tue, Dec 17, 2013 at 12:21 AM, Torben Knerr [ukio@gmx.de](mailto:ukio@gmx.de) wrote:

> Another possible caveat:
> 
> Shouldn't it be 'ruby\_block "ls /tmp #{count}" do' ?
> 
> -Torben  
> On Dec 17, 2013 6:39 AM, "Noah Kantrowitz" [noah@coderanger.net](mailto:noah@coderanger.net) wrote:
> 
> > The more generic solution is to use resources/LWRPs such that the second  
> > resource isn't compiled until after the settings you care about. For  
> > example  
> > [https://github.com/balanced-cookbooks/ci/blob/master/libraries/ci\_server.rb#L45-L46](https://github.com/balanced-cookbooks/ci/blob/master/libraries/ci_server.rb#L45-L46)
> > 
> > --Noah
> > 
> > On Dec 16, 2013, at 9:18 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)  
> > wrote:
> > 
> > > This seems like such a simple problem and something that everyone  
> > > should come across at one point or another.
> > > 
> > > Here's a short snippet of code that illustrates the issue I'm having:
> > > 
> > > (1..2).each do |count|  
> > > ruby\_block "ls /tmp" do  
> > > block do  
> > > node.set['test1']['lsdir'] = %x[ls /tmp]  
> > > end  
> > > end
> > > 
> > > file "/tmp/file#{count}.txt" do  
> > > content node['test1']['lsdir']  
> > > end  
> > > end
> > > 
> > > So, at the end of the run, both /tmp/file1.txt and /tmp/file2.txt are  
> > > empty. I had hoped for /tmp/file2.txt to show that '/tmp/file1.txt now  
> > > exists.
> > > 
> > > I know this is because the value of attributes are evaluated during the  
> > > compile phase at the beginning of the chef run and at that time, the value  
> > > of node['test1']['lsdir'] is nil. Also, this same issue arises when trying  
> > > to use a variable instead of an attribute.
> > > 
> > > How can I get something like this to execute as I would have hoped?  
> > > This has to be a common pattern; set an attribute, use it, modify the  
> > > attribute, use the new value. I know there is the new 'lazy' delayed  
> > > evaluator, but I can only get that to work when used in a value for a  
> > > resource attribute.
> > > 
> > > Thanks
> > > 
> > > --  
> > > John Alberts

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![Rilindo\_Foster1](https://avatars.discourse-cdn.com/v4/letter/r/8e8cbc/32.png) [@Rilindo\_Foster1](https://discourse.chef.io/u/Rilindo_Foster1)\
**Post date:** [December 17, 2013, 5:37pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/6 "2013-12-17T17:37:16Z")

</div>

On Dec 17, 2013, at 10:50 AM, John Alberts \<[john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)[mailto:john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)\> wrote:

Thanks everyone for the responses. So… it seems the consensus is that this is best done in a LWRP. I had considered doing that, it just seemed like overkill for what should be a simple operation; that being, change the value of a variable(or attribute) and use that variable again later in the code.

Slightly off-topic, but where are you modifying It may be a style or philosophy thing, but I personally wouldn’t try to modify an attribute once I declare it. I rather that I set my conditions up front in attributes file and maybe override them as necessary within the environment role. Changing them within the recipe strikes me as adding a significant amount of complexity to the code maintenance, as you now have to look at the recipes AND attributes when you modify the cookbook.

Rilindo Foster

---

<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:** [December 17, 2013, 6:03pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/7 "2013-12-17T18:03:11Z")

</div>

On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster \<  
[Rilindo.Foster@exlibrisgroup.com](mailto:Rilindo.Foster@exlibrisgroup.com)\> wrote:

> Slightly off-topic, but where are you modifying It may be a style or  
> philosophy thing, but I personally wouldn't try to modify an attribute once  
> I declare it. I rather that I set my conditions up front in attributes file  
> and maybe override them as necessary within the environment role. Changing  
> them within the recipe strikes me as adding a significant amount of  
> complexity to the code maintenance, as you now have to look at the recipes  
> AND attributes when you modify the cookbook.

Yes, I agree. Here's the actual scenario that I'm dealing with. I'm  
creating some new EBS volumes, once they are created, I store those new  
device entries in an attribute. Later in the code, I need to use those new  
devices to either format, create a raid, etc. So, I need to save those  
device values somewhere during the Chef run and be able to use them later  
in the code.

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![John\_Keiser1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_keiser1/32/202_2.png) [@John\_Keiser1](https://discourse.chef.io/u/John_Keiser1)\
**Post date:** [December 17, 2013, 7:19pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/8 "2013-12-17T19:19:00Z")

</div>

I wonder if there is a chef\_sugar-ish solution we could build for  
this--it's awfully common. I suspect it is possible to write a  
"all\_together\_resource" resource that let you write:

all\_together do  
lsdir = 0  
(1..2).each do |count|  
ruby\_block "ls /tmp" do  
block do  
lsdir = %x[ls /tmp]  
end  
end

```
file "/tmp/file#{count}.txt" do
  content lsdir
end

```

end  
end

This would create an all\_together\_resource resource which will execute the  
entire block in its action :run, with each resource running immediately as  
soon as the resource is declared.

On Tue, Dec 17, 2013 at 10:03 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster \<  
> [Rilindo.Foster@exlibrisgroup.com](mailto:Rilindo.Foster@exlibrisgroup.com)\> wrote:
> 
> > Slightly off-topic, but where are you modifying It may be a style or  
> > philosophy thing, but I personally wouldn't try to modify an attribute once  
> > I declare it. I rather that I set my conditions up front in attributes file  
> > and maybe override them as necessary within the environment role. Changing  
> > them within the recipe strikes me as adding a significant amount of  
> > complexity to the code maintenance, as you now have to look at the recipes  
> > AND attributes when you modify the cookbook.
> 
> Yes, I agree. Here's the actual scenario that I'm dealing with. I'm  
> creating some new EBS volumes, once they are created, I store those new  
> device entries in an attribute. Later in the code, I need to use those new  
> devices to either format, create a raid, etc. So, I need to save those  
> device values somewhere during the Chef run and be able to use them later  
> in the code.
> 
> --  
> 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:** [December 17, 2013, 9:07pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/9 "2013-12-17T21:07:30Z")

</div>

Interesting thought. Sounds like a new weekend project. 🙂

On Tue, Dec 17, 2013 at 11:19 AM, John Keiser [jkeiser@getchef.com](mailto:jkeiser@getchef.com) wrote:

> I wonder if there is a chef\_sugar-ish solution we could build for  
> this--it's awfully common. I suspect it is possible to write a  
> "all\_together\_resource" resource that let you write:
> 
> all\_together do  
> lsdir = 0  
> (1..2).each do |count|  
> ruby\_block "ls /tmp" do  
> block do  
> lsdir = %x[ls /tmp]  
> end  
> end
> 
> ```
> file "/tmp/file#{count}.txt" do
> content lsdir
> end
> 
> ```
> 
> end  
> end
> 
> This would create an all\_together\_resource resource which will execute the  
> entire block in its action :run, with each resource running immediately as  
> soon as the resource is declared.
> 
> On Tue, Dec 17, 2013 at 10:03 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:
> 
> > On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster \<  
> > [Rilindo.Foster@exlibrisgroup.com](mailto:Rilindo.Foster@exlibrisgroup.com)\> wrote:
> > 
> > > Slightly off-topic, but where are you modifying It may be a style or  
> > > philosophy thing, but I personally wouldn't try to modify an attribute once  
> > > I declare it. I rather that I set my conditions up front in attributes file  
> > > and maybe override them as necessary within the environment role. Changing  
> > > them within the recipe strikes me as adding a significant amount of  
> > > complexity to the code maintenance, as you now have to look at the recipes  
> > > AND attributes when you modify the cookbook.
> > 
> > Yes, I agree. Here's the actual scenario that I'm dealing with. I'm  
> > creating some new EBS volumes, once they are created, I store those new  
> > device entries in an attribute. Later in the code, I need to use those new  
> > devices to either format, create a raid, etc. So, I need to save those  
> > device values somewhere during the Chef run and be able to use them later  
> > in the code.
> > 
> > --  
> > John Alberts

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![John\_E\_Vincent\_lusis](https://avatars.discourse-cdn.com/v4/letter/j/c89c15/32.png) [@John\_E\_Vincent\_lusis](https://discourse.chef.io/u/John_E_Vincent_lusis)\
**Post date:** [December 18, 2013, 3:50pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/10 "2013-12-18T15:50:48Z")

</div>

I see a couple of more "flexible" options. I think node.run\_state would  
work here but I'm not positive without testing it.

Another option that I've always found interesting is creating/using a  
databag as part of a recipe. It's a bit risky in that the databag is just  
out there without a commensurate copy in your repo though.

Really this feels like the job of an LWRP. There's a lot of logic you're  
describing that would really muddy a recipe.

On Tue, Dec 17, 2013 at 1:03 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster \<  
> [Rilindo.Foster@exlibrisgroup.com](mailto:Rilindo.Foster@exlibrisgroup.com)\> wrote:
> 
> > Slightly off-topic, but where are you modifying It may be a style or  
> > philosophy thing, but I personally wouldn't try to modify an attribute once  
> > I declare it. I rather that I set my conditions up front in attributes file  
> > and maybe override them as necessary within the environment role. Changing  
> > them within the recipe strikes me as adding a significant amount of  
> > complexity to the code maintenance, as you now have to look at the recipes  
> > AND attributes when you modify the cookbook.
> 
> Yes, I agree. Here's the actual scenario that I'm dealing with. I'm  
> creating some new EBS volumes, once they are created, I store those new  
> device entries in an attribute. Later in the code, I need to use those new  
> devices to either format, create a raid, etc. So, I need to save those  
> device values somewhere during the Chef run and be able to use them later  
> in the code.
> 
> --  
> John Alberts

---

<div class="post-metadata">

**Author:** ![Dan\_Razzell](https://avatars.discourse-cdn.com/v4/letter/d/ed655f/32.png) [@Dan\_Razzell](https://discourse.chef.io/u/Dan_Razzell)\
**Post date:** [December 18, 2013, 6:17pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/11 "2013-12-18T18:17:13Z")

</div>

Isn't the issue only that %x[ls /tmp] is being evaluated at compile time?  
Avoid that notation and you'll be able to do what you intend. Use "system"  
instead and it will be evaluated as part of the ruby block.

On Tue, Dec 17, 2013 at 10:03 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster \<  
> [Rilindo.Foster@exlibrisgroup.com](mailto:Rilindo.Foster@exlibrisgroup.com)\> wrote:
> 
> > Slightly off-topic, but where are you modifying It may be a style or  
> > philosophy thing, but I personally wouldn't try to modify an attribute once  
> > I declare it. I rather that I set my conditions up front in attributes file  
> > and maybe override them as necessary within the environment role. Changing  
> > them within the recipe strikes me as adding a significant amount of  
> > complexity to the code maintenance, as you now have to look at the recipes  
> > AND attributes when you modify the cookbook.
> 
> Yes, I agree. Here's the actual scenario that I'm dealing with. I'm  
> creating some new EBS volumes, once they are created, I store those new  
> device entries in an attribute. Later in the code, I need to use those new  
> devices to either format, create a raid, etc. So, I need to save those  
> device values somewhere during the Chef run and be able to use them later  
> in the code.
> 
> --  
> John Alberts

---

<div class="post-metadata">

**Author:** ![Sean\_OMeara1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sean_omeara1/32/207_2.png) [@Sean\_OMeara1](https://discourse.chef.io/u/Sean_OMeara1)\
**Post date:** [December 18, 2013, 10:19pm UTC](https://discourse.chef.io/t/delayed-evaluation/4814/12 "2013-12-18T22:19:12Z")

</div>

There's also a fundamental misunderstanding about how to use Chef going on  
here...

A Chef resource is a test-and-repair datastructure. It lives in a compiled  
resource\_collection and is meant to describe some policy point about the  
system.

This example is trying to use one Chef resource to harvest information from  
the system, use the node objetc as global state tracking mechanism, then  
use another resource one to ensure its contents of a file.

The best thing to do would be to restate the problem. Start every system  
with "I declare".

"I declare that the file /tmp/file-1 should have the output of `ls /tmp` as  
its content.

There are a couple different ways to solve this, but the easiest would be  
to stash the contents of your ls in a compile phase variable and pass it as  
a parameters to your file resources.

# this is not a resource. It will be discarded after the compile phase

lsdir shell\_out!("ls /tmp", :env =\> nil)

# these are.

file "/tmp/file1" do  
content lsdir  
end

file "/tmp/file2" do  
content lsdir  
end

On Wed, Dec 18, 2013 at 1:17 PM, Dan Razzell [danr@activestate.com](mailto:danr@activestate.com) wrote:

> Isn't the issue only that %x[ls /tmp] is being evaluated at compile time?  
> Avoid that notation and you'll be able to do what you intend. Use "system"  
> instead and it will be evaluated as part of the ruby block.
> 
> On Tue, Dec 17, 2013 at 10:03 AM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:
> 
> > On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster \<  
> > [Rilindo.Foster@exlibrisgroup.com](mailto:Rilindo.Foster@exlibrisgroup.com)\> wrote:
> > 
> > > Slightly off-topic, but where are you modifying It may be a style or  
> > > philosophy thing, but I personally wouldn't try to modify an attribute once  
> > > I declare it. I rather that I set my conditions up front in attributes file  
> > > and maybe override them as necessary within the environment role. Changing  
> > > them within the recipe strikes me as adding a significant amount of  
> > > complexity to the code maintenance, as you now have to look at the recipes  
> > > AND attributes when you modify the cookbook.
> > 
> > Yes, I agree. Here's the actual scenario that I'm dealing with. I'm  
> > creating some new EBS volumes, once they are created, I store those new  
> > device entries in an attribute. Later in the code, I need to use those new  
> > devices to either format, create a raid, etc. So, I need to save those  
> > device values somewhere during the Chef run and be able to use them later  
> > in the code.
> > 
> > --  
> > 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:** [December 19, 2013, 12:07am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/13 "2013-12-19T00:07:57Z")

</div>

On Wed, Dec 18, 2013 at 2:19 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com) wrote:

> There's also a fundamental misunderstanding about how to use Chef going on  
> here...

I completely understand what you're saying and I agree that my original  
example is a bad example of what I'm trying to accomplish which is creating  
a raid volume from 2 newly created ebs volumes.

So... to use your suggestion of declaration: 'I declare this system should  
have a raid 0 volume created from 2 new EBS volumes.'

--  
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:** [December 19, 2013, 12:10am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/14 "2013-12-19T00:10:06Z")

</div>

On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell [danr@activestate.com](mailto:danr@activestate.com) wrote:

> Isn't the issue only that %x[ls /tmp] is being evaluated at compile time?  
> Avoid that notation and you'll be able to do what you intend. Use "system"  
> instead and it will be evaluated as part of the ruby block.

I thought any ruby code inside a ruby block will not be evaluated during  
compile time and instead during the normal order of the execution phase. I  
haven't tested this yet, but does it really matter if inside that ruby  
block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [December 19, 2013, 12:37am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/15 "2013-12-19T00:37:58Z")

</div>

you are right , when you pass a block inside a ruby\_block resource's block  
attribute, its not invoked during the compile phase (unless you do  
run\_action(:run) hacks). The challenge is how you capture this computed  
value and pass it back to another resource. node.run\_state is one way of  
doing it. but again this is hacky. Also when reusing the coputed value you  
have to ensure the consumer ruby code is also evaluated in the execution  
phase, not it compile phase. i.e. another ruby\_block resource where the  
block parameter is accessing node.run\_state will work, but file resource's  
content attribute is evaluated during compile time , even if you do content  
node.run\_state[:value\_from\_other\_ruby\_blockl], you are accessing a value  
that is not computed yet.

look this is hacky, but this will work:

ruby\_block "foo" do  
block do  
node.run\_state[:troll] = `ls /tmp`  
end  
end.run\_action(:run)

file "/etc/bar" do  
content node.run\_state[:troll]  
end

i think use cases like this shows that we really dont have tow independent  
resources, rather they are coupled where one of them is dependent on  
other's attribute value. hence it might be worth to cleanly implement it in  
an lwrp where.

On Wed, Dec 18, 2013 at 4:10 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell [danr@activestate.com](mailto:danr@activestate.com)wrote:
> 
> > Isn't the issue only that %x[ls /tmp] is being evaluated at compile  
> > time? Avoid that notation and you'll be able to do what you intend. Use  
> > "system" instead and it will be evaluated as part of the ruby block.
> 
> I thought any ruby code inside a ruby block will not be evaluated during  
> compile time and instead during the normal order of the execution phase. I  
> haven't tested this yet, but does it really matter if inside that ruby  
> block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?
> 
> --  
> John Alberts

---

<div class="post-metadata">

**Author:** ![Sean\_OMeara1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sean_omeara1/32/207_2.png) [@Sean\_OMeara1](https://discourse.chef.io/u/Sean_OMeara1)\
**Post date:** [December 19, 2013, 12:40am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/16 "2013-12-19T00:40:32Z")

</div>

You want to implement this as an atomic operation from within a custom  
provider.

On Wed, Dec 18, 2013 at 7:10 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell [danr@activestate.com](mailto:danr@activestate.com)wrote:
> 
> > Isn't the issue only that %x[ls /tmp] is being evaluated at compile  
> > time? Avoid that notation and you'll be able to do what you intend. Use  
> > "system" instead and it will be evaluated as part of the ruby block.
> 
> I thought any ruby code inside a ruby block will not be evaluated during  
> compile time and instead during the normal order of the execution phase. I  
> haven't tested this yet, but does it really matter if inside that ruby  
> block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?
> 
> --  
> 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:** [December 19, 2013, 12:48am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/17 "2013-12-19T00:48:46Z")

</div>

Thanks again to everyone for their input. I think it's been decided beyond  
a shadow of a doubt that I should implement this in a custom provider. 🙂

A question to Ranjib's example; where can I find more information about  
node.run\_state? I only see mention of it regarding a windows provider and  
really no where else.

On Wed, Dec 18, 2013 at 4:40 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com) wrote:

> You want to implement this as an atomic operation from within a custom  
> provider.
> 
> On Wed, Dec 18, 2013 at 7:10 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:
> 
> > On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell [danr@activestate.com](mailto:danr@activestate.com)wrote:
> > 
> > > Isn't the issue only that %x[ls /tmp] is being evaluated at compile  
> > > time? Avoid that notation and you'll be able to do what you intend. Use  
> > > "system" instead and it will be evaluated as part of the ruby block.
> > 
> > I thought any ruby code inside a ruby block will not be evaluated during  
> > compile time and instead during the normal order of the execution phase. I  
> > haven't tested this yet, but does it really matter if inside that ruby  
> > block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?
> > 
> > --  
> > John Alberts

--  
John Alberts

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [December 19, 2013, 1:47am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/18 "2013-12-19T01:47:31Z")

</div>

i cant think of any standard docs, except i some blogs out there that  
recommended using it for temporary storage (the dude from nordstorm?) . I  
knew its there, but never used it. When i first encountered it in our code  
base (it was sumologic cookbook's sumo\_source definition), i had changed it  
to an hwrp.

iirc node.run\_state was used to detect loaded recipes (remember currently  
only recipes that are assigned via run list are present inside node.recipes  
not the ones which applied via included\_recipe), there was some breaking  
changes during chef 10-\> 11 migration too,

On Wed, Dec 18, 2013 at 4:48 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:

> Thanks again to everyone for their input. I think it's been decided  
> beyond a shadow of a doubt that I should implement this in a custom  
> provider. 🙂
> 
> A question to Ranjib's example; where can I find more information about  
> node.run\_state? I only see mention of it regarding a windows provider and  
> really no where else.
> 
> On Wed, Dec 18, 2013 at 4:40 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com) wrote:
> 
> > You want to implement this as an atomic operation from within a custom  
> > provider.
> > 
> > On Wed, Dec 18, 2013 at 7:10 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com)wrote:
> > 
> > > On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell [danr@activestate.com](mailto:danr@activestate.com)wrote:
> > > 
> > > > Isn't the issue only that %x[ls /tmp] is being evaluated at compile  
> > > > time? Avoid that notation and you'll be able to do what you intend. Use  
> > > > "system" instead and it will be evaluated as part of the ruby block.
> > > 
> > > I thought any ruby code inside a ruby block will not be evaluated during  
> > > compile time and instead during the normal order of the execution phase. I  
> > > haven't tested this yet, but does it really matter if inside that ruby  
> > > block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?
> > > 
> > > --  
> > > John Alberts
> 
> --  
> John Alberts

---

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [December 19, 2013, 3:34am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/19 "2013-12-19T03:34:27Z")

</div>

May I recommend the ebs\_raid LWRP in the aws cookbook?

- Julian

On Wed, Dec 18, 2013 at 7:07 PM, John Alberts [john.m.alberts@gmail.com](mailto:john.m.alberts@gmail.com) wrote:

> On Wed, Dec 18, 2013 at 2:19 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com) wrote:
> 
> > There's also a fundamental misunderstanding about how to use Chef going on  
> > here...
> 
> I completely understand what you're saying and I agree that my original  
> example is a bad example of what I'm trying to accomplish which is creating  
> a raid volume from 2 newly created ebs volumes.
> 
> So... to use your suggestion of declaration: 'I declare this system should  
> have a raid 0 volume created from 2 new EBS volumes.'
> 
> --  
> John Alberts

--  
[Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com) \* Sorry, I'm ]  
[WWW: [Julian Dunn's Blog - Commentary on media, technology, and everything in between.](http://www.aquezada.com/staff/julian) \* only Web 1.0 ]  
[gopher://sdf.org/1/users/keymaker/ \* compliant!]  
[PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9]

---

<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:** [December 19, 2013, 3:43am UTC](https://discourse.chef.io/t/delayed-evaluation/4814/20 "2013-12-19T03:43:36Z")

</div>

On Wed, Dec 18, 2013 at 7:34 PM, Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com) wrote:

> May I recommend the ebs\_raid LWRP in the aws cookbook?

Thanks for reminding me about that. I completely forgot it was added to  
the aws cookbook a while back.

--  
John Alberts

[Next page](https://discourse.chef.io/t/delayed-evaluation/4814.md?page=2)