Difference between revisions of "Puppet"
(→Running local tests) |
|||
Line 8: | Line 8: | ||
The following modules exist: | The following modules exist: | ||
+ | * stackforge/puppet-ceilometer | ||
* stackforge/puppet-cinder | * stackforge/puppet-cinder | ||
* stackforge/puppet-glance | * stackforge/puppet-glance | ||
Line 16: | Line 17: | ||
* stackforge/puppet-openstack_dev_env | * stackforge/puppet-openstack_dev_env | ||
* stackforge/puppet-swift | * stackforge/puppet-swift | ||
− | |||
The most up to date version of the modules is available on https://review.openstack.org/#/ | The most up to date version of the modules is available on https://review.openstack.org/#/ | ||
e.g. https://review.openstack.org/gitweb?p=stackforge/puppet-keystone.git;a=summary | e.g. https://review.openstack.org/gitweb?p=stackforge/puppet-keystone.git;a=summary | ||
− | === | + | === GitHub mirrors === |
All of the modules are also mirrored to GitHub here | All of the modules are also mirrored to GitHub here | ||
Line 31: | Line 31: | ||
=== Branches === | === Branches === | ||
− | The master branch of each module corresponds to the master branch of the current | + | The master branch of each module corresponds to the master branch of the current OpenStack core projects. Once released, a new branch will be created and should be considered stable. |
− | For example, the current master branch of stackforge/puppet-keystone is for grizzly, once released a new grizzly branch will be created, from that point | + | For example, the current master branch of stackforge/puppet-keystone is for grizzly, once released a new grizzly branch will be created, from that point onward the master branch should target the Havana release. |
=== Releases === | === Releases === | ||
− | Master version of the modules will be released as a new major version to Puppet Forge (forge.puppetlabs.com) when its related version of | + | Master version of the modules will be released as a new major version to Puppet Forge (forge.puppetlabs.com) when its related version of OpenStack is released. |
− | Each version of | + | Each version of OpenStack will have a related release on the forge (fosom = 1.x, grizzly = 2.x) |
− | When patches are accepted against a branch | + | When patches are accepted against a branch targeting a stable version, this will trigger a new release to that module on the forge. |
NOTE: the automatic triggered forge releases still have not been setup, this process will have to be manual until this is completed. | NOTE: the automatic triggered forge releases still have not been setup, this process will have to be manual until this is completed. | ||
Line 53: | Line 53: | ||
* Debian 7.0 (Wheezy) | * Debian 7.0 (Wheezy) | ||
− | The modules have been primarily tested on Puppet 2.7.x and Ruby 1.8.7, although they are also being used | + | The modules have been primarily tested on Puppet 2.7.x and Ruby 1.8.7, although they are also being used with Puppet 3.1.x, 3.0.x, with Ruby 1.9.3. |
− | with Puppet 3.1.x, 3.0.x, with Ruby 1.9.3. | ||
Puppet 2.6.x is currently supported, but that support will be dropped soon b/c it has been EOL'ed by PuppetLabs | Puppet 2.6.x is currently supported, but that support will be dropped soon b/c it has been EOL'ed by PuppetLabs | ||
Line 88: | Line 87: | ||
==== Getting Started ==== | ==== Getting Started ==== | ||
− | To contribute you now follow the same process as all of the other | + | To contribute you now follow the same process as all of the other OpenStack projects. |
The following docs contain sufficient information to get started: | The following docs contain sufficient information to get started: | ||
Line 103: | Line 102: | ||
Any users can +/- 1 a commit and add comments on commit, but only members of the puppet-manager-core group have the ability to +2 and approve code to be merged. | Any users can +/- 1 a commit and add comments on commit, but only members of the puppet-manager-core group have the ability to +2 and approve code to be merged. | ||
− | Puppet OpenStack CI, and | + | Puppet OpenStack CI, and SmokeStack are two continuous integration environments that can be used to verify that any given patch can be used to deploy a functional multi-node environments. The integration of both of these systems is an ongoing process, so failures should be followed up on, but are not considered blockers at this moment. |
=== Patches === | === Patches === | ||
− | Patches waiting to be merged can be viewed in | + | Patches waiting to be merged can be viewed in Gerrit e.g. for stackforge/puppet-keystone |
https://review.openstack.org/#/q/status:open+project:stackforge/stackforge/puppet-keystone,n,z | https://review.openstack.org/#/q/status:open+project:stackforge/stackforge/puppet-keystone,n,z | ||
Line 116: | Line 115: | ||
==== Downloading a local patch ==== | ==== Downloading a local patch ==== | ||
− | Clone the relevant module from | + | Clone the relevant module from StackForge, ex: |
git clone git://github.com/stackforge/puppet-openstack | git clone git://github.com/stackforge/puppet-openstack | ||
Line 144: | Line 143: | ||
=== Rspec puppet tests === | === Rspec puppet tests === | ||
− | Rspec puppet tests are a requirement for getting code merged into the | + | Rspec puppet tests are a requirement for getting code merged into the StackForge modules. |
− | |||
− | |||
− | + | The best reference for getting started with rspec-puppet can be found [http://rspec-puppet.com/ here] | |
==== Running local tests ==== | ==== Running local tests ==== | ||
Line 156: | Line 153: | ||
It assumes that both bundler as well as rubygems (and ruby) are already installed on the system. | It assumes that both bundler as well as rubygems (and ruby) are already installed on the system. | ||
− | + | mkdir vendor | |
− | + | export GEM_HOME=vendor | |
− | + | bundle install | |
− | + | # bundle exec rake -T | |
− | + | bundle exec rake spec | |
− | |||
This relies on the file .fixtures.yaml to install all of the external module required for testing. | This relies on the file .fixtures.yaml to install all of the external module required for testing. | ||
The urls in this file use the git:// protocol, so this may need to be updated if you are behind a proxy. | The urls in this file use the git:// protocol, so this may need to be updated if you are behind a proxy. |
Revision as of 03:51, 12 June 2013
Introduction
The Puppet openstack modules were written as a collaborative effort between operators deploying openstack environments.
Modules
All of the modules for the openstack project are hosted under StackForge.
The following modules exist:
- stackforge/puppet-ceilometer
- stackforge/puppet-cinder
- stackforge/puppet-glance
- stackforge/puppet-horizon
- stackforge/puppet-keystone
- stackforge/puppet-nova
- stackforge/puppet-openstack
- stackforge/puppet-openstack_dev_env
- stackforge/puppet-swift
The most up to date version of the modules is available on https://review.openstack.org/#/ e.g. https://review.openstack.org/gitweb?p=stackforge/puppet-keystone.git;a=summary
GitHub mirrors
All of the modules are also mirrored to GitHub here
https://github.com/stackforge/
Note : GitHub should not be used for pull requests / bugs reports
Branches
The master branch of each module corresponds to the master branch of the current OpenStack core projects. Once released, a new branch will be created and should be considered stable.
For example, the current master branch of stackforge/puppet-keystone is for grizzly, once released a new grizzly branch will be created, from that point onward the master branch should target the Havana release.
Releases
Master version of the modules will be released as a new major version to Puppet Forge (forge.puppetlabs.com) when its related version of OpenStack is released.
Each version of OpenStack will have a related release on the forge (fosom = 1.x, grizzly = 2.x)
When patches are accepted against a branch targeting a stable version, this will trigger a new release to that module on the forge.
NOTE: the automatic triggered forge releases still have not been setup, this process will have to be manual until this is completed.
Supported Platforms
The following OS/version are supported by the modules:
- Fedora 18
- RHEL 6.4
- Ubuntu 12.04 (Precise)
- Debian 7.0 (Wheezy)
The modules have been primarily tested on Puppet 2.7.x and Ruby 1.8.7, although they are also being used with Puppet 3.1.x, 3.0.x, with Ruby 1.9.3.
Puppet 2.6.x is currently supported, but that support will be dropped soon b/c it has been EOL'ed by PuppetLabs
Getting Help
Mailing list
In general, the mailing list is preferred, because it makes the information more readily available so that others who have the same question can search for and find those answers.
puppet-openstack@puppetlabs.com
IRC
Or on an irc channel on freenode
#puppet-openstack
IRC logs can be found here:
http://irclog.perlgeek.de/puppet-openstack/
Submitting issues
Issues and features should be submitted under the puppet-openstack project on Launchpad:
https://launchpad.net/puppet-openstack/
Developer documentation
Contributing to the modules
Getting Started
To contribute you now follow the same process as all of the other OpenStack projects.
The following docs contain sufficient information to get started:
- https://wiki.openstack.org/wiki/How_To_Contribute
- https://wiki.openstack.org/wiki/GettingTheCode
- https://wiki.openstack.org/wiki/GerritWorkflow
- go to : settings > watched projects and add the puppet projects (all of the form stackforge/puppet-*)
How code gets merged
Code is merged based on the voting process of the modules in Gerrit. All submitted patches automatically trigger a job that runs its rspec-puppet tests. This job is considered to be a gate in that no code is allowed to be merged that does not pass these tests. The results of this job are listed for every patch as a +1 Verified vote from Jenkins.
Any users can +/- 1 a commit and add comments on commit, but only members of the puppet-manager-core group have the ability to +2 and approve code to be merged.
Puppet OpenStack CI, and SmokeStack are two continuous integration environments that can be used to verify that any given patch can be used to deploy a functional multi-node environments. The integration of both of these systems is an ongoing process, so failures should be followed up on, but are not considered blockers at this moment.
Patches
Patches waiting to be merged can be viewed in Gerrit e.g. for stackforge/puppet-keystone
https://review.openstack.org/#/q/status:open+project:stackforge/stackforge/puppet-keystone,n,z
Q. How do I go about submitting a patch for a released branch, what the correct process? Unless is not relevant all patches should be approved for the master branch before you submit them for a stable branch. This ensures we maintain stability in the stable branches and functionality
Downloading a local patch
Clone the relevant module from StackForge, ex:
git clone git://github.com/stackforge/puppet-openstack
in the patch, find the git checkout or cherry-pick command, and copy it:
git fetch https://review.openstack.org/stackforge/puppet-openstack refs/changes/52/29452/9 && git checkout FETCH_HEAD
if you wanted to update an existing patch:
make a topic branch:
git checkout -b my_topic
make your changes:
hack,hack,hack
amend the current commit:
git commit --amend .
now resubmit:
git review
Rspec puppet tests
Rspec puppet tests are a requirement for getting code merged into the StackForge modules.
The best reference for getting started with rspec-puppet can be found here
Running local tests
The following command can invoked from any if the modules' directories to run their rspec puppet tests.
It assumes that both bundler as well as rubygems (and ruby) are already installed on the system.
mkdir vendor export GEM_HOME=vendor bundle install # bundle exec rake -T bundle exec rake spec
This relies on the file .fixtures.yaml to install all of the external module required for testing. The urls in this file use the git:// protocol, so this may need to be updated if you are behind a proxy.