Jump to: navigation, search

Chef/GettingStarted

< Chef
Revision as of 20:04, 21 May 2013 by Jaypipes (talk | contribs)

This page serves as a getting started guide for community members interested in contributing to the OpenStack Chef cookbooks and example repository.

Communication

The OpenStack + Chef community has a mailing list on Google Groups. Join the conversation: https://groups.google.com/forum/?fromgroups=#!forum/opscode-chef-openstack

There is an #openstack-chef channel on Freenode.net. Come hang out with us and collaborate there.

Bug Tracking

We track bugs and feature requests using a single Launchpad project called OpenStack + Chef. You can see the list of open bugs or file a new bug.

Blueprints / Feature Tracking

For major feature enhancements and planning you can use Launchpad's Blueprints system for the OpenStack + Chef project on Launchpad. You can create a new blueprint that may be targeted to a milestone and tracked appropriately.

Code

The canonical upstream Chef cookbooks and example repository are located in the Stackforge Github organization. There is a single Chef cookbook for each integrated OpenStack project:


In addition to the project cookbooks, there are three support cookbooks:


As well as an example Chef Repository that sets up an OpenStack environment:

Contributing to the OpenStack Chef Cookbooks

See this blog entry for an introduction to contributing and pushing code to for the OpenStack Chef cookbooks housed on Stackforge.

Guidelines for Commit Messages

Please try to make commit messages useful. Read this excellent blog post, as well as the standard commit message guidelines for OpenStack projects before making your first code push.

Guidelines for Code Reviewers

Here are some simple rules for reviewers of code on the Gerrit Review site:

Rule #1: Never +1/+2R or +1A your own patch.

Rule #2: All patches must have a commit message that meets the standard commit message guidelines for OpenStack projects. Failure of the commit message to meet these guidelines should prevent a +1A by a core reviewer.

Rule #3: If the patch is more than just stylistic or typo fixes, it requires at least 2 core reviewers to add a +2R to the review before any core reviewer can +1A the review.

Rule #4: If the patch changes existing behavior of any cookbook in a backwards-incompatible way, a corresponding bump in the version in the cookbook's metadata.rb must be included in patch set. Failure to do so should prevent a +1A by a core reviewer.

Rule #5: If the patch adds additional functionality to a library cookbook, a corresponding bump in version number in the metadata.rb file should accompany the patch. Failure to do so should prevent a +1A by a core review.