Jump to: navigation, search

Difference between revisions of "Packstack"

m (Links)
Line 89: Line 89:
=== Bugs ===
=== Bugs ===
Bugs are tracked in https://bugzilla.redhat.com/ ([https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20OpenStack&component=openstack-packstack New bug])
Bugs are tracked in Launchpad ([https://bugs.launchpad.net/packstack New bug])
=== Reviews ===
=== Reviews ===

Revision as of 13:56, 29 August 2013


/!\ This page is far from complete, help by adding information.


Packstack is a utility that uses Puppet modules to deploy various parts of OpenStack on multiple pre-installed servers over SSH automatically. Currently only Fedora, Red Hat Enterprise Linux (RHEL) and compatible derivatives of both are supported.

Example Usage : All in One

Example Usage : Controller / multiple compute nodes

Example Usage : Swift Proxy / multiple storage devices

Development : Getting started

git clone --recursive https://github.com/stackforge/packstack.git -b folsom
cd packstack
python ./bin/packstack --gen-answer-file=ans.txt
# edit ans.txt
python ./bin/packstack --answer-file=ans.txt




Developers meet in #packstack-dev on Freenode for discussion.

Packstack Development

Making your first contribution

The process you need to follow in order to contribute to packstack is the same as the openstack core projects, documented here http://wiki.openstack.org/HowToContribute the steps to follow look something like this

  • Sign the CLA
  • get the code
$ git clone --recursive https://github.com/stackforge/packstack.git 
  • Make your change and commit it
  • Submit your change for review
   $ git review 
   $ git add -p
   $ git commit --amend
   $ git review

Git branches

There is a branch for each openstack major release, this branch starts off is life as master, once development of the next release starts, it will be renamed and then master will be the branch for the next openstack release e.g. once we start grizzly development, master will branch off a folsom branch. Then

  • folsom -> should only accept bug fixes and exceptional approved new features, these should be merged into master first if appropriate
  • master -> new features for grizzly and bugs

note : (be careful to send your changes to the correct branch and also that your basing any commits on a parent from the correct branch)

# to send review request for the master branch
git review 

# to send review request for the stable branch
git review folsom

Git submodules

We pull many other puppet submodules from various places, these are added as git submodules. A git submodule references a particular commit, In as much as possible packstack should reference the most recent upstream puppet modules possible, this may involve getting some changes into the puppet module before changing the commit referenced by packstack.

Once a release has been branched off, we should never change the reference to a newer upstream commit, If a new commit is required in the puppet module the appropriate procedure is


Bugs are tracked in Launchpad (New bug)


All commits should be reviewed and approved by at least one core packstack member (ideally 2 for any commit more then a trivial change) and author of a commit shouldn't approve their own code.

New Features

New features go into the master branch. There may be new features committed to a stable branch but these should be the exception and not the norm.


Open review requests https://review.openstack.org/#/q/status:open+project:stackforge/packstack,n,z

packstack core

You do not need to be a core member to packstack in order to contribute code. Members of packstack-core can approve commits in gerrit to be merged into the code, new members to packstack-core should be actively (and reliably) reviewing commits in gerrit before being considered. New members will be invited to join. Core members can be found here