[chef] Re: Re: raise_unless

[Daniel DeLeo < >]

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.