[chef] Re: Re: Re: Exposing attributes from cookbooks you depend on

["Hajducko, Steven" < >]

So I read over the httpd and mysql and saw what you meant about using LWRP's 
in lieu of attributes.

My question is - when's the right time to do this and when does it make sense 
to use normal cookbooks with attributes?

In my case, the cobbler cookbook is exposing LWRP's for some parts of it's 
configuration ( distros, profiles, etc ).  Anything that you can have many of.

However, when you have a singleton service ( ie - the actual 'cobbler' server 
), does it make sense to shove it into an LWRP or just stay with the the 
normal include_recipe and some configuration attributes? Is there somewhere 
that I missed that using attributes for configuration driven recipes is a bad 
idea?

--
sh

________________________________________
From: Lamont Granquist 
<
 >
Sent: Friday, March 20, 2015 9:20 AM
To: 

 
Cc: Hajducko, Steven; Torben Knerr
Subject: Re: [chef] Re: Re: Exposing attributes from cookbooks you depend on

That's ideal philosophically, but is probably going to produce bad chef
code.  One you've hit the computed attributes issue and worked around it
by moving setting attributes in recipes and exposed yourself to
compile/converge issues and started down the path of probably needing to
use 'lazy' attributes, then I'd rethink the idea of re-namespacing the
attributes.

On 3/20/15 2:09 AM, Torben Knerr wrote:
> My preference on this is to re-namespace the attributes the user is
> expected to set. I think of it as the "public interface" of a wrapper
> cookbook that is tested and also documented in the README.
>
> Cheers, Torben
>
> On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist 
> <
 >
>  wrote:
>> On 3/19/15 1:53 PM, Hajducko, Steven wrote:
>>
>> Provserv is a wrapper ( and the name is made up ) - it does its own things
>> as well, so it's probably best to call it an application cookbook that's
>> depending on another application cookbook.  It's also business specific to
>> us.  The cobbler cookbook is meant to, in the end, be shared with the
>> community.
>>
>> The cobbler attributes that need to be set however, need to be set per
>> environment.  We'll have several of the 'provserv' applications running,
>> each in its own environment.
>>
>> My question was about whether people generally re-namespace these 
>> attributes
>> when you have a cookbook you're depending on and you need to expose those
>> configurable attributes to the user.
>>
>> In our case, we'd be setting all these in a Chef environment.  But, do I
>> expose them as:
>>
>> default["provserv"]["dhcp"]["gateway"] = 1.1.1.1
>>
>> and in the recipe:
>>
>> node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]
>>
>>
>> yeah, don't set that attribute in the recipe.
>>
>> you probably set it in the recipe because you hit the interpolated
>> attributes problem in the attributes file.
>>
>> its better to just use default["cobbler"]["dhcp"]["gateway"] in the
>> attributes file of the proserv cookbook.
>>
>>