[chef] Re: Re: Re: Re: Re: raise_unless

[Klaas Jan Wierenga < >]

+1 for raise_unless (or similar) in an attributes file

If you think of the attributes file as the 'API' of the recipe then I would prefer to have something in the attributes file so it is a full specification of all required attributes. How this specification is then used to assert that all required attributes are set is a matter of implementation. The error raising should probably be part of evaluation the recipe.

Regards,
K-J

On Mon, Jul 19, 2010 at 6:49 PM, Daniel DeLeo < "> > wrote:

On Fri, Jul 16, 2010 at 4:27 PM, Adam Jacob < "> > wrote:
> Actually, you can do:
>
> include_attribute "foo"
>
> To ensure it gets loaded first.
>
> +1 for raise_unless

I considered this, but I don't think it's sufficient for the problem
at hand. Every decent-sized chef deployment I've ever looked at uses
roles to denormalize the majority of explicitly-set attributes. Role
attributes aren't applied to the node until after attribute files are
read, so if you have this in an attribute file:
   raise_unless(attribute_foo)
And this in a role:
   default_attributes(:attribute_foo => "bar")
The attribute file would always raise when evaluated, even though chef
would have set that attribute soon afterward. You could still put your
`raise_unless` statement in a recipe as `node.raise_unless` though.
But maybe this is enough to cover the use case? If it was a resource,
I'm imagining something like

   fail_if("This host does not have  a domain name set.") do
     assert { node[:domain] }
   end

It would probably be necessary to run this immediately (or at least
have an option to do so).

I'm +1 on the idea in either case, though I think an implementation
that encourages use from within recipes is favorable to one that does
not.

Dan DeLeo

>
> 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: ">
>

-- 
Groeten,

Klaas Jan
 
 ">