Future of Opscode Cookbooks

We’re making changes to the Opscode cookbooks repository about what cookbooks we include and how we provide support for them. As a large number of people rely on our cookbooks, we want to be clear about the intentions of the repository, and how we plan to release and support cookbooks going forward.

The cookbooks in our GitHub repository are the only ones maintained by us. We will provide bug fixes and help in using them. Opscode Platform customers will get direct support in using our cookbooks, other assistance will be as it is now with best effort help via IRC, mailing list or questions/comments on the Community Site itself. Any other cookbook the community wants to exist should be maintained in their own source code repositories, github or otherwise, and published to the Community Site like ours are.

Over the time since its original release, the Chef project has matured, and in most cases changed quite dramatically. We also created a centralized site where the Chef Community can share their own cookbooks with other users. All of Opscode’s cookbooks are published to the site, and several members of the community have shared theirs as well. Since we see Chef cookbooks as individual packages for managing some component of an infrastructure, we think of the Community site as a package repository similar to other focused package sites such as rubygems.org or cpan.org. We will continue to release our supported cookbooks to the Community Site, and our supported, maintained cookbooks will be developed in the GitHub repository.

Cookbooks that we can reasonably support and maintain fall into three categories:

As this implies, we will remove a number of cookbooks that no longer fall into those categories from our GitHub repository. Cookbooks that are deprecated will be marked as such on the Community Site, with a pointer to the replacement cookbook, where appropriate. All cookbooks will remain on the cookbooks site, and of course the GitHub repository will have the history so you would be able to go back in time to a previous point in time. If you are interested in taking over maintenance of a particular cookbook, we’d be happy to turn that over to you, by making you the maintainer on the Community Site. Without further ado, here is the list of cookbooks that we’re going to remove from the GitHub repository. If you’d like to maintain any, please reply to this post.

  • capistrano – deprecated: use the application cookbook (rails, django or php recipes set up a capistrano deployment structure).
  • django – deprecated: use the application cookbook (django recipe).
  • dynomite – deprecated: upstream project is no longer maintained.
  • ec2 – deprecated: cookbook only sets attributes that were not used anywhere else.
  • glassfish – unsupported: use “application” and “tomcat” for our recommended java stack deployment.
  • instiki – unsupported: was used as a rails app deployment example, no longer relevant/useful.
  • java_sun – deprecated: use ‘java’.
  • nanite – deprecated: use rabbitmq::chef for setting up chef-server’s queue.
  • one-shot – unsupported: doesn’t fit in with any currently supported guides or usage patterns.
  • packages – deprecated: this was only used with the older chef-server bootstrap recipes and its functionality is no longer needed.
  • passenger_enterprise – unsupported: this cookbook doesn’t fall into a deployment path for using passenger and rails applications.
  • quick_start – deprecated: doesn’t provide any real-world usefulness, only used for contrived example purposes.
  • rabbitmq_chef – deprecated: use rabbitmq::chef.
  • rails – deprecated: use application::rails to deploy rails applications.
  • rails_enterprise – deprecated: use application::rails to deploy rails applications; installing REE should be done via a bootstrap template.
  • redmine – deprecated: this was written as a Rails deployment example, and it doesn’t fall under the RedMine project’s recommended installation procedure.
  • riak – unsupported: Basho Technologies (Sean Cribbs) will maintain this cookbook.
  • ruby – deprecated: the desired default ruby should be installed on target nodes with the knife bootstrap sub-command.
  • ruby_enterprise – deprecated: use a custom knife bootstrap template to install REE.
  • rubygems – deprecated: this doesn’t provide anything useful that a properly written Gemfile and using the bundler deployment in application::rails (or similar) couldn’t already provide
  • rush – unsupported: this is a toy and doesn’t provide useful value
  • solr – unsupported: this cookbook is limited in its usage and was ported from a legacy automation system
  • teamspeak – unsupported: deprecated, see teamspeak3
  • teamspeak3 – unsupported: replaces teamspeak, but no longer maintained by Opscode directly
  • tomcat6 – deprecated: use “tomcat” cookbook.

Additionally, we have two new cookbooks specifically related to the Chef 0.10 server installation:

  • chef-server
  • gecode

For a preview of what this looks like, the 0.10.0 branch in the Opscode Cookbook repository reflects these changes now. Please let us know if you have any questions. If you would like to become the maintainer of any cookbooks listed above, let us know your Community site username.

Author Joshua Timberman

Joshua Timberman is a Code Cleric at CHEF, where he Cures Technical Debt Wounds for 1d8+5 lines of code, casts Protection from Yaks, and otherwise helps continuously improve internal technical process.

  • Glad to see this logical evolution to clean things up and clarify responsibilities so that you guys can focus. Though it looks like most of the cookbooks with current value are already covered, I’d suggest that new maintainers might use git filter-branch to split off cookbooks into new repositories with their own history maintained.

  • Avishai

    I’d like to take over the Solr cookbook. Let me know if you’re interested. (community name: avishai)

    • Thank you, I’ve made you the maintainer on the community site. You’ll want to modify the home page on it to point to your preferred source repository, too.

  • Anonymous

    I’d like to take over the redmine cookbook to polish the installation procedure. A LWRP for installing plugins could come handy as well. ;)

  • How about packaging cookbooks as rubygems?

    IMHO, the process of making my own gems has become very easy (thanks to gemcutter & rubygems improvements since 1.3.5).

    And bundler makes managing gems a breeze, whether from official sources, or community git forks.

  • Pingback: Update on the Future of Opscode’s Cookbooks | Opscode.com()