Thanks to the hard work of the puppet-openstack community, Puppet was the preferred method of deployment for Openstack in the latest Openstack User Survey.
If you’d like to join in on the fun and contribute, read on !
First things first, a bit of context:
- Openstack is a modular cloud orchestration platform, self-described as “Open source software for building private and public clouds”.
- puppet-openstack is a Stackforge project that centralizes the development of puppet modules related to Openstack. puppet-openstack is also an actual module allowing the installation and configuration of core Openstack services.
- Stackforge is used to host Openstack-related projects so that they can benefit from the same continuous integration infrastructure and review system that the main Openstack projects use such as Nova.
Now that we have the basics out of the way, if you’d like to contribute to Openstack in general, it’s not mandatory to have any programming or networking knowledge. There’s always things like documentation and translation that need manpower.
The contribution process for puppet-openstack is slightly different than committing code to primary Openstack projects (such as Nova) and I won’t be highlighting them here for the sake of simplicity - this is a topic for another blog post !
I recently started contributing as part of the new puppet-ceph initiative so this blog post more or less describes what I had to go through to get my first contribution in.
Okay, sign me up. ¶
If you want to join in on the fun, the basic instructions for signing up are pretty well documented on the Openstack Wiki: https://wiki.openstack.org/wiki/How_To_Contribute
In a nutshell:
- Sign up a Launchpad account, this will be used to login to the Gerrit review system used by Openstack continuous integration: https://launchpad.net/+login
- Join the Openstack Foundation, this is free and required for contributing to Openstack: https://www.openstack.org/join/
- Agree to the Individual Contributor’s License Agreement (CLA)
- If you’re going to be comitting code on behalf of an organization, you’ll need to have a Corporate Contributor’s License Agreement (CCLA) in addition to the individual CLA.
- Start contributing !
Getting started ¶
Let’s say I want to develop for puppet-ceph (!), I’ll keep these resources handy:
- The Launchpad project for bugs/issues/fixes/feature/backlog documentation and discussion: https://bugs.launchpad.net/puppet-ceph (each project has it’s own launchpad project)
- The developer documentation will prove useful to prepare your development environment and beyond. For puppet modules, documentation is provided both on the Openstack Wiki and directly in the README files.
Clone the project ¶
You’re going to need the puppet module source to work on it, you can either clone it from Github:
or from Gerrit:
Make sure you have ruby, rubygems and bundle installed ¶
First of all, you’ll need ruby and bundle to manage ruby packages (gems).
These will be required, especially when the time will come to do spec/integration/lint tests.
If you already have them you can skip this part !
apt-get install ruby rubygems ruby-bundler
apt-get install ruby rubygems bundler
Install development dependencies ¶
With the help of bundle, fetch and install the gem dependencies documented in the Gemfile located at the root of the repository.
Create your branch and do your stuff ¶
Create a branch with a name relevant to what you’re doing
git checkout -b feature/my_feature
Now you can do your modifications.
Don’t forget to add new spec tests or modify existing ones to match the modifications you made to the module.
Test your stuff ¶
You’ve added or modified some code, now you want to test it:
Test for puppet syntax (puppet-lint):
bundle exec rake lint
Run spec tests (puppet-rspec)
bundle exec rake spec
If you try to push code that doesn’t pass the tests, jenkins will not let you through - better make sure everything is okay before sending something for review!
Tests are successful ? Add and commit your stuff ¶
git add [file] git commit
Make sure your commit message follows the right format !
Send your stuff for review ¶
That’s it ! Your code was sent to gerrit for review by the community and the core reviewers !
Jenkins or someone -1’d my code. Help ! ¶
Maybe you did a typo or something far worse you’d like to fix - this is done by submitting another patch set.
Do the changes you want to do, add the files again but instead of using ‘git commit‘, use ‘git commit —amend‘.
This will essentially modify the initial commit.
After amending your commit, send the code back for a new review with ‘git review‘ once more.