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

[Dreamcat4 < >]

On Sat, Aug 7, 2010 at 6:24 PM, Dreamcat4 
<
 >
 wrote:
> 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.

Sorry I didnt mean to say theres any deficiency.

Lets see again...
> 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?

It makes sense to reserve have raise_unless() function in the
recipe.rb files like Daniel says. But we could also accompany that
with a more broader and flexible addition to the attribute syntax in
the attribute.rb file.

For example:

attributes.rb:
include_attribute(OtherCookbook::OtherAttribute)

Would show that this cookbook uses / pinches / steals some attribute
from another cookbook and what that specifically is. Then its more
useful because it can espress optional attributes too.

So for example there might be plenty of cases where an optional
extension or module/plugin can interact with another program. Eg
mod_php for apache. Then that attributes from php cookbook can
*optionally* be set. Its quite useful.

Not just for the raise_unless, but also for any parts of a recipe
which might have

recipe.rb:
if (other_cookbook_attribute)
  # install optional plugin
end

and so wouldnt necessarily need this raise_unless checking in all
instances of this usage. This is more expressive and flexible, I think
for J-K and different enough not to be a duplication of efforts and
aim at solving the 2 distinct different kinds of problems.

Of course if you actually used raise_unless() in your recipe file you
might also want to have a matching includes_attribute() line in the
attributes.rb. But thats just common sense and not necessarily a
duplication of things.


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