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

[Dreamcat4 < >]

Hi,
Its also worthwhile to address Daniel's point about the role
attributes. Perhaps that represents a more general architectural
inconsistency between the sources for configuration attributes.

Lets see...
In most cases an attribute dependency in the other recipe should
usually be filled in with a default value. Wheras a role value could
be different, and override that with any other arbitrary value.

Perhaps the role configuration can (in some cases) can require the
defaults to be cleared, emptied, nil'd. Typically for an "either-or"
scenario whereby you have to choose one or the other backend, eg "it
requires either MYSQL or POSTGRES, but not both".

It then would require (to catch that inconsistency) in the recipe file
with a raise_unless for the zero'd attribute(s). But in all other
cases it wont as there should be a default attribute. That is either
overrided to a role value (or left to the default).

Am I right?

On the other side we have someone like K-J here who dutifully looks
through the attributes.rb files to decide what to set his role values
should be when creating a new role definition. K-J would see the
raise_unless statements in there more easily, and be sure set up those
dependant attributes up (in the other CBs) also.

If raise_unless were allways only in the recipe files, K-J would feel
uneasy, or somehow more obliged to have to carefully trawl through all
the whole recipes to get that same information.

OTOH (again), if K-J just didnt bother trawling through and gave it a
run, would not quickly find the Chef::Exception saying "hey you didnt
set this value in the other recipe", if the other recipe had set a
default to the value for that particular require'd attribute.

So K-J (presumably a chef attributes junkie that he is) wouldn't
really be aware of that extra configuration attribute he could
possible set differently and tailored to his role.


So to summarize:

One way is best for guaranteeing that the role attrubite value is set
(but not caring if it was overriden from the default?). That is
Daniels put it in the recipe way.

The other way is best choice for showing that some attribute in a
dependant recipe is "taken in" or inherited, and being shared between
both recipes as a first-class attribute. So thats when raise_unless is
in the attributes.rb file. You can really see its a part of the
cookbook you are looking at, even though the attribute belongs from a
different cookbook.

Maybe thats a subtly different kind of a problem and the raise_unless
idiom is not the best way to represent these shared attributes?


On Sat, Aug 7, 2010 at 12:13 PM, Klaas Jan Wierenga
<
 >
 wrote:
> +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
> 
 
>
>