Jump to: navigation, search

Difference between revisions of "Packstack"

(Example Usage : Controller / multiple compute nodes)
(Example Usage : Controller / multiple compute nodes)
Line 21: Line 21:
 
== Example Usage : Controller / multiple compute nodes ==
 
== Example Usage : Controller / multiple compute nodes ==
  
'''TODO.'''
+
<code><nowiki>TODO.</nowiki></code>
  
 
== Example Usage : Swift Proxy / multiple storage devices ==
 
== Example Usage : Swift Proxy / multiple storage devices ==

Revision as of 13:57, 30 November 2014

Packstack

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

Summary

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

packstack --allinone

Shorthand for:

packstack --install-hosts=<local ipaddr> --novanetwork-pubif=<dev> --novacompute-privif=lo --novanetwork-privif=lo --os-swift-install=y --nagios-install=y

This option can be used to install an all in one OpenStack on this host.

Example Usage : Controller / multiple compute nodes

TODO.

Example Usage : Swift Proxy / multiple storage devices

Development : Getting started

Installation of Packstack

$ yum install git -y
$ git clone https://github.com/stackforge/packstack.git
$ cd packstack && sudo python setup.py install

Installation of openstack-puppet-modules (Required if running packstack from source)

$ sudo python setup.py install_puppet_modules

Using an answer file

$ packstack --gen-answer-file=answers.txt

Then edit answers.txt as appropriate e.g.

  • Set CONFIG_SSH_KEY to a public ssh key to be installed to remote machines
  • Edit the IP address to anywhere you want to install a piece of opentack on another server
  • Edit the 3 network interfaces to whatever makes sense in your setup

Links

Presentations

IRC

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

End-user questions are probably best answered in #openstack or #rdo

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 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 juno development, master will branch off a juno branch. Then

  • juno → should only accept bug fixes and exceptional approved new features, these should be merged into master first if appropriate
  • master → new features for juno 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 juno

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

Bugs are tracked in Launchpad (New bug)

Reviews

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.

gerrit

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