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

[Lamont Granquist < >]

We're heading in the direction where library cookbooks should only 
expose LWRPs for the most part.   All the attributes should be exposed 
instead as parameters on LWRPs.  Once those resources are mature then 
eventually they can get migrated into core chef.

Similar pattern can be used internally so that you'd have LWRPs to wrap 
your definition of what a generic 'application' is in your 
infrastructure so that the listen_port becomes a parameter instead of an 
attribute.  Then what attributes get used for is things where you'd like 
to twiddle them via roles or role cookbooks.  So having one cookbook 
which manages /etc/resolv.conf makes sense, but then you might need to 
tweak the search path in different roles if you've got some complicated 
internal DNS domains on the servers you are managing.  You can still do 
that via LWRPs but then you need to call that LWRP in every single role 
that you have which is going to be more complicated than just having a 
base role that manages /etc/resolv.conf and then exposes attributes to 
override.  I'd probably use attributes in that case, and it makes it 
naturally searchable and that distinction is something that I'd probably 
like to search on and see in the node data.

So instead of using attributes for everything, start with LWRPs, and 
then use attributes when their properties are actually desired.

Sean O'Meara has been giving talks about this, he'll be talking about it 
at ChefConf, I think there's blog posts and slides up on the web 
somewhere but I'm not sure where...

On 3/20/15 9:24 AM, Hajducko, Steven wrote:
> 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.