[chef] Re: Re: Re: Re: Re: Re: delayed evaluation?


Chronological Thread 
  • From: John Keiser < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: delayed evaluation?
  • Date: Tue, 17 Dec 2013 11:19:00 -0800

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

On Tue, Dec 17, 2013 at 9:37 AM, Rilindo Foster < " target="_blank"> > 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




Archive powered by MHonArc 2.6.16.

§