[chef] Re: Re: Re: Re: Re: Re: good example of chef definitions ? need help with issue below

[Lamont Granquist < >]

Right, you can do that, but its fussy.  And like I said that is just a symptom.  The worse problems come later when you don't know where those LWRPs are going to be in the run_list, and you only want to trigger the resource that writes out the file once, so you use a delayed notification -- but now nothing in your run_list can depend on that file getting updated first.  It works much better to collect all the information at compile-time, and then execute the resource for the file the first time the definition is encountered in the run_list.  That way every recipe that comes after the first time the definition is encountered will see the file updated, and you don't have to manually worry about ordering.   If you try to do it with an LWRP then you wind up pondering hacks to make it run at compile-time like chef_gem or other issues like that, and like dan wrote you wind up wanting to include_recipe from within an LWRP to avoid users having to manually insert a special resource in their run_list at the correct spot.  If you use a definition everything just works the way you want it to (because you really want compile-time reusable code rather than convergence-time reusable code).

On 10/5/13 12:17 AM, Ranjib Dey wrote:

" type="cite">

the providers can always introspect loaded recipes and raise an error if its absent. you can have a convention that "to use the lwrp you have to include the default recipe of the same cookbook". but the fact that you will be able to chain it those lwrp into other lwrp is immense. definitions has been particularly been painful to extend.  take any community cookbook and start extending it, u'll realize cookbooks that give definitions are particularly trouble some, cause you cant predict their behavior in nested environments. use_inline_resource has been a blessing :-) , i really cant think of a compelling reason to use definition now (post chef 11)  unless you run really old chef . i 'll be very interested to know what others think?   

On Fri, Oct 4, 2013 at 11:51 PM, Lamont Granquist < " target="_blank"> > wrote:

On 10/4/13 12:38 PM, Ranjib Dey wrote:

i dont think anyone should use definition, iirc a debate where we were discussing deprecating them (or at least not advocating them), as steve pointed out, they are more like macro expansion, but since chef run is dual phases, macro expansion has subtle consequences. they pretty much blocks building higher abstraction on top of them.

LWRPs are generally going to be the first tool to reach for.  But if you're trying to manage a single file like /etc/sudoers, /etc/aliases, /etc/sysconfig/iptables, /etc/sysctl.conf, /etc/sshd/known_hosts, etc across multiple recipes then a definition can be useful to collect all the information across all the cookbooks and manage the file with a single resource (and manage the whole file as a template and avoid the need for multiple edit-in-place resources to manage it).  Trying to do that with an LWRP gets annoying, particularly when you want the resource to get managed sooner rather than later, using a definition means you can gather all the information compile-time and then manage the resource at the point in the resource collection where the first definition is invoked.  Then later recipes can rely on the resource having been set already (sysctls are set, firewall rules in place, etc).  With an LWRP approach you typically wind up with this problem of wanting a default recipe that users must put at the right spot in their run_lists in order to mange the resource and the LWRP then sends a notification to that resource and that's a symptom that you're not doing it right.

But, that's advanced Chef usage, and the average newbie who doesn't understand any of that is better off just reaching for an LWRP... 98% of the time an LWRP is going to be the right answer, but there is that 2% where a definition works a lot better than an LWRP...