Puppet OpenStack achievements during Newton cycle

Let’s do a quick retro.

Pilot: “OpenStack tower, request for landing N-E-W-T-O-N and immediate takeoff.”
Tower: “Request approved. Prepare your takeoff to O-C-A-T-A – Good work folks!”.


That’s how I would summarize this cycle. We’re about to release final Newton in a few weeks and we’ll immediately work on Ocata cycle for shorten time.
I thought a blog post that summarize what Puppet OpenStack project did would be useful.


Official support for Ubuntu Xenial

It was one of our challenges, to support and test Puppet OpenStack modules deployments on Ubuntu Xenial. Despite a good number of problem we had to solve, we made it and you can now upgrade Ubuntu to Xenial and deploy OpenStack Newton using our modules. Our CI is gating on Ubuntu Xenial, and we will leave Ubuntu Trusty behind us, still gating on Liberty and Mitaka gates.


Official support of Puppet 4

We already managed to deploy Puppet OpenStack modules on Puppet 4 during Mitaka cycle, but Newton cycle will be the first release where we officially support this version. Starting from Ocata, we’ll remove Puppet 3 jobs and switch the voting jobs to Puppet 4. Liberty, Mitaka and Newton CI jobs will still run Puppet 3 jobs. Newton CI will also run and gate on Puppet 4. Please read this thread for more context.


Standardization of Keystone authtoken

In this cycle, we deprecated old authtoken parameters and now every module has its own class to configure [authtoken] section in configuration files. It’s 100% backward compatible and old parameters will be removed during Ocata cycle. Please see this bug for more context. In other words, all projects mentioned in the bug report should now be able to be configured to talk with Keystone with the most recent parameters, specially for Keystone v3, in a consistent way.


Documentation moved

The new shiny Puppet OpenStack guide is now available here. We moved out from Wiki since it’s being retired soon. Contributions are welcome to make it better!


Testing OpenStack trunk

Thanks to RDO community, Puppet CI is able to test OpenStack from trunk and bring a shorter feedback loop to OpenStack community when we find a bug. That’s awesome! Even if our CI breaks more often, we were able to track down many bugs and backward incompatible changes in OpenStack, which is something very valuable for us. We’re on the edge of what is developed in OpenStack. Also, RDO CI is now using Puppet CI scripts to run functional tests, so we are consistent in what and how we test OpenStack.


New modules in our family

  • puppet-oslo is now used by all our modules to configure oslo.cache, oslo.concurrency, oslo.cors, oslo.db, oslo.logging, oslo.messaging (with all backends), oslo.middleware, oslo.privsep, oslo.service and oslo.versionedobjects. It bring more consistency in our way to configure OpenStack.
  • puppet-barbican is now ready for production, we are running Tempest scenarios in its gate and test Volume encryption.
  • puppet-ovn is now ready for production, TripleO is using it to deploy OVN.
  • New modules still in progress: puppet-congress, puppet-ec2api, puppet-panko, puppet-octavia, puppet-tacker, puppet-vitrage and puppet-watcher.

It brings our forge up to 40 Puppet modules (libraries, doc, CI repos are excluded) and it keeps growing!


Thank you for all the¬†contributions. I had so much fun to be the PTL of Puppet OpenStack during the last 18 months. I learnt so many things, on technical and human point of views. I’m super exciting about¬†future and I’m looking forward to kick-off Ocata cycle with our awesome community.

“OpenStack tower, ready to takeoff.”

Software Engineeer at Red Hat, Private Pilot, French guy hiding somewhere in Canada.