[chef] Re: Re: Re: Re: Re: [chef-dev] Ownership Changes of Chef Cookbooks Revisited

[Rajiv Ranganath < >]

On Sun, May 25, 2014 at 12:41 PM, Lamont Granquist 
<
 >
wrote:
>
> I would really like to see Chef not be the SPOF for cookbook sharing and
> governance.  I would love to see someone aggressively fork the community
> site and implement their own code quality standards, supported features and
> governance.  Because as long as we think we're trying to produce the one
> apache cookbook that works on every RHEL, Debian, Ubuntu, Gentoo, Arch,
> Solaris and AIX distro for the past 10 years and supports binary and source
> installation, etc we're going to produce a mess which satisfies almost
> nobody.  The models of rubygems and CPAN and other library sites for
> languages are a really bad metaphor for this domain because we don't just
> have the problem of running on a few different versions of a language, but
> running on a huge matrix of different O/Ses and distros and all the ways
> that sysadmins like to maintain their servers.  There will never be the
> OneTrueWayToInstallApache.

We have already started doing this for Amazon Linux.

Our focus is on producing a **supported** set cookbooks that codifies
and complies very closely to AWS Security and Architecture Best
Practices. Where we can't fully automate, we provide extensive
documentation on how the cookbook should be used.

As an example of how we do this, please see -

https://github.com/lambda-linux-cookbooks/ll-postgresql-devops-helper
https://github.com/lambda-linux-cookbooks/ll-yum#ll_yum_createrepo
https://github.com/lambda-linux-cookbooks/ll-postgresql

There are a number of quality standards that we implement in our
cookbooks. I'll highlight a few here,

1.  We manually audit every cookbook to ensure that there is no funny
    business going on and aggressively prune out code paths that are not
    relevant to our context.

2.  We have a much shallower dependency chain. As a general rule
    we do not exceed two levels of dependency as complexity increases
    exponentially for every additional level of cookbook dependency.
    This is bad for security.

    In addition, all `ll-COOKBOOKS` depend only on other `ll-COOKBOOKS`.
    This means entire dependency chain is audited.

3.  We have a very strong notion of public APIs in our cookbooks. If
    we break public APIs (documented default attributes, recipes) for
    our users, we will fix it.

    Most of our cookbooks are designed to be used via wrapper-cookbook
    and base-cookbook patterns.

4.  We separate out build-time vs. run-time concerns in cookbooks. Our
    preferred approach is to build the packages separately and inject
    them where necessary into the workflow. This approach removes the
    need for `build-essential` in many cookbooks and also significantly
    reduces the time needed to complete Chef Run.

There are more things that we do, but you get the idea. :-)

If you are on Amazon Linux/EC2, feel free to check out and use the
cookbooks that we've already published at,

https://github.com/lambda-linux-cookbooks

I don't mean to hijack this thread. Lamont is making a **very** good
point and I wanted to give an example of what is possible.

If this is an approach that is interesting to you, I'll be at DevOps
Days Silicon Valley and we can continue the conversation there. I can
also show you some other things this approach allows us to do.

Thank you!

Best,
Rajiv