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

[Ranjib Dey < >]

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