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