Share this post

Openstack+Puppet

David Moreau Simard

4 minute read

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.

For contributing to puppet-openstack in particular, however, it is required to be (or become!) familiar with ruby, puppet, puppet-rspec and of course, Openstack..

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:

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 !

On Ubuntu:

On Debian:

 

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

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):

Run spec tests (puppet-rspec)

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

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.