[chef] Re: Re: Re: raise_unless


Chronological Thread 
  • From: Adam Jacob < >
  • To:
  • Subject: [chef] Re: Re: Re: raise_unless
  • Date: Fri, 16 Jul 2010 16:27:21 -0700

Actually, you can do:

include_attribute "foo"

To ensure it gets loaded first.

+1 for raise_unless

Adam

On Fri, Jul 16, 2010 at 8:36 AM, Daniel DeLeo 
< >
 wrote:
> On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer 
> < >
>  wrote:
>>
>> Someone told me I didn't explain what I was asking well enough, so here is
>> an attempt to do that.
>> I have some configurations where there is not really a sensible default and
>> I want to ensure the cookbook parameters are pushed down from another
>> cookbook or role.
>> I want the opposite behavior of set_unless[:foo][:bar], I want
>> raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not set.
>> I monkey patched Chef::Node to make raise_unless work. There is some
>> differences in the way node interacts with attributes between 0.8 and 0.9
>> that make it different between versions, but it's pretty straight forward.
>> I'm interested if other people see any use for this and if so, is there a
>> better semantic or mechanism to accomplish it.
>
> If you use this in an attributes file, it's tricky since Chef doesn't
> guarantee the attribute files are loaded in any order (except when
> using include_attribute, which only ensures one attribute file will be
> loaded before the other). Also, it seems fair that you would set this
> critical attribute in a role, in which case it would not be set until
> after the attribute files were read.
>
> So in my view, you'd want to put this in a recipe file, and if you put
> it there, it might make sense to use a more general "assert" method
> and define it on Chef::Recipe or even make it a LWRP. Then you could
> make assertions about the system state outside of Chef if you needed
> to. On the other hand, maybe I'm architecture astronaut-ing.
>
> I like the idea though, many times new users have not set their FQDN
> before running the bootstrap and then been confused by the "attribute
> domain is not defined" error. It would be much nicer to see that the
> attribute is not defined and abort with a message about setting the
> domain name.
>



-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: 




Archive powered by MHonArc 2.6.16.

§