CODEWITHSUNDEEP
chef-infrachef-recipe
Mayank Jain
Mayank Jain

Reputation: 3205

When using open source Chef cookbooks - should we clone or reference in Berksfile?

Say I am building my /my_company_cookbooks collection and I want to use an awesome community cookbook from Github.

I have two options

  1. Reference the cookbook from github by adding a line to my Berksfile (cookbook 'graphite', git: 'git://github.com/hw-cookbooks/graphite.git' )
  2. Local copies - Clone the cookbook into my /my_company_cookbooks folder and keep a local reference to it.

Each strategy seem to have merits and disadvantages.

Github merits

Github disadvantages - How do I ascertain that my production cookbooks depend on exactly the version of cookbooks which I tested on staging. Author can forget to bump cookbook version while still making code changes. Untested code changes will then reach my production environment

Local copies merits I can test and push to production with 100% certainty & debugging is easier

Local copies disadvantages

Any thoughts or best practices in this matter?

Thanks

Upvotes: 1

Views: 186

Answers (2)

Mark O'Connor
Mark O'Connor

Reputation: 77971

Where possible consume the cookbooks from the community "supermarket" repository. For example the following will retrieve the latest version of graphite:

source 'https://supermarket.chef.io'

cookbook "graphite"

The documentation shows that this cookbook is managed by the heavywater dudes:

Why? When consuming cookbooks from source code repositories, you run the small risk of loading an alternative copy of the same version into your chef server.

Huh? Explain please!

Take the following scenario:

  1. The chef developer makes a small change to his cookbook, but does not increment the cookbook version number, 1.1
  2. You pull down what you think is version 1.1 of the cookbook.
  3. The chef developer makes a more substantial change the cookbook, but again does not increment the version number (because he's not ready to release).

Your chef server now has a copy of version 1.1 that does not match the latest copy of version 1.1 in the version control system....

To complicate matters you need to explicitly run a "berks update" followed by a forced reload of the cookbook into your chef server (remember berkshelf freezes cookbooks) in order to fix this problem..... This can become a non trivial issue and I have been burned by it more than once (Bizarrely the openstack cookbooks are not available from supermarket).

At the end of the day consume from source if you're on first name terms with the other development team :-) Another solution if you crave stability is to only consume from Git tags, a best practice that cookbooks loaded into the chef supermarket do follow.

What the Chef supermarket provides is a release management process for chef cookbooks. Git is supposed to track all changes to the files within the cookbook. But it cannot detect when a cookbook is ready for a release. That is the job of the developer and if he behaves and follows a sensible workflow he'll tag his code and then push it into some sort of repository for downloading by 3rd parties. It is this process and storage facility that supermarket provides. It's your friend I highly recommend using it :-)

Apologies for the long rant! Therapeutic :-)

Upvotes: 3

Tensibai
Tensibai

Reputation: 15784

Quoting the Berkshelf documentation:

GitHub Location

As of version 1.0.0, you may now use GitHub shorthand to specify a location.

cookbook "artifact", github: "RiotGames/artifact-cookbook", tag: "0.9.8" Given this example, the artifact cookbook from the RiotGames organization in the artifact-cookbook repository with a tag of 0.9.8 will be cloned to the berkshelf.

I assume this remove the disadvantage of github, and then you just have no reason to refrain using it now.

Upvotes: 2

Related Questions