[chef] Re: Re: Centralized cookbook-library repos vs distributed cookbook repos

[dreamcat four < >]

Hi,
Yeah the right cookbook structure for the complex ones... I am still
learning so take with a pinch of salt? Beyond a certain level of
complexity it makes sense to hide them behind a custom domain-specific
resource. Then its good to try to encapsulate / hide the more complex
sequences within /libraries/ LWRP, Definition or custom
resource+provider. Then make it clear how to use those special
resouces.

Split into multiple recipes files. (sorry about the line wrapping here)
eg;
  recipes/base.rb                       <---- hopefully, users dont
have to touch this
  recipes/user_example.rb          <---- show users how to use your
custom resource
  recipies/user_customized1.rb   <---- user can add their own file

Good to include an example json file (easily runnable by chef solo) in
files/default/ folder. To demonstrate how to overload your json
attributes, and let people have a way to quickly test it out the whole
recipe.

As for documentation, its not good to leave the readme.rdoc file
empty. Its free-form so i guess maybe that puts some people off when
they dont know what content to put in it?

Maybe if the documentation is just extra metadata within the source
code. So what about a yard plugin for chef? The author of yard has
provided some interesting examples including one that allows yard to
understand rspec tests. Chef resources (and other chef objects) may be
documentable in this way too. If thats a sensible goal to aim for.
However it would take a general consensus amongst contributors to
actually document their cookbooks.

Not sure everyone is onboard with that idea yet :(

On Fri, Apr 9, 2010 at 2:59 PM, Dan DeMaggio 
<
 >
 wrote:
> On Fri, Apr 9, 2010 at 3:30 AM, Hedge Hog 
> <
 >
>  wrote:
>> The large fork count actually seems to be the problem.
>
> I don't think we will have "one cookbook to rule them all". For
> example, take the Apache cookbook.  The Opscode cookbook recipe takes
> the "kitchen sink" approach, and tries to insulate the recipe _user_
> from making any changes to the apache config.  There are over 70 files
> in the recipe, and it can take a day just to read and understand all
> that code and all the 'tweakable' settings. But if they missed a
> setting, have to decide "at which layer (chef or apache) do I fix the
> problem?"
>
> I took the opposite approach: I was fine with requiring the recipe
> _writer_ to make changes, so I started with my existing Apache config,
> and added a little chef magic specific to our organisation.  The
> ability to change the Apache port or tune the number of workers
> (without editing the config) just wasn't worth the added layers of
> complexity (to me).
>
> So, I don't think there can be one single cookbook recipe that will
> work for a large hosting provider (generating 1000's of virtual hosts)
> and a small websites (that just wants to set up few rails proxies).
> One is likely to use looping within a single recipe to generate
> vhosts, the other is likely to use a definition called from multiple
> recipes to generate vhosts.
>
> The bigger problem right now is that we've got 100's of example
> cookbooks, but no explanation of WHY the people did what they did.
>
> -=Dan=-
>