[Openstack-operators] OpenStack Operators Atlanta Puppet Meetup Summary
chris.hoge at puppetlabs.com
Tue May 27 17:27:36 UTC 2014
I was asked to repost this from the puppet-openstack mailing list. My
apologies if you have received this twice.
Summary of Atlanta OpenStack Summit Puppet Operators Meetup
Thanks to everyone who attended the Puppet Operators Meetup at the Atlanta
OpenStack Summit. The aim of the session was to coordinate the efforts of
operators and developers for managing OpenStack deployments with Puppet. We
had a fantastic turnout from both communities, and we had a chance to
exchange feedback on how Puppet is being used to manage production
We started the discussion by taking stock of who was using Puppet, and how
they were using it. Nearly 20 organizations were represented, with a range
of deployment cases. Most were using the community developed
puppet-openstack modules available on Stackforge, with the majority of
those users pulling directly from GitHub. By running from either master or
the latest stable branch, operators were able to get the latest patches and
also patch the modules to meet their specific needs. Some organizations are
deploying with their own custom modules, with the smallest group drawing
from the packaged modules on the Puppet Forge.
>From there the conversation moved on to user experiences with Puppet and
OpenStack. This discussion focused largely on the puppet-openstack modules.
One of the biggest problems operators face is with the problem of upgrading
from one OpenStack release to another using the Puppet modules. Upgrading
in general is a difficult problem, and the additional abstraction layer of
Puppet adds its own issues. Being able to use multiple versions of the
modules, staging rollouts, and being able to roll back are all problems
that users are facing. While there is no explicit facility for using the
modules to update installations, it is a problem that clearly deserves
everyone's attention. As a first step, we're going to start a thread on the
puppet-openstack mailing list where users can describe their upgrade
methodologies and experiences so that we can start building out documents
for best practices, and writing tools to automate those practices.
Another problem faced by operators is how to have their local changes
reviewed and merged back into the upstream code. There's a disconnect
between the speed at which operators need to submit and have changes
merged, and the speed which allows rigorous review and testing. We came to
a couple of action points in which developers agreed to give more timely
reviews for new contributors, but to also take over patches that need
additional testing or code coverage.
Other issues included: code stability, orchestration, parameter
deprecation, and documentation. We aim to improve code stability with more
integration testing, and several organizations pledged CI testing. We're
encouraging the discussion of how operators are orchestrating their
installations on the puppet-openstack mailing list, without prejudice on
the tools that they're using. We will be doing a review of the code base
and working up a deprecation parameter removal policy, as well as auditing
and improving the documentation of the modules.
The puppet-openstack project is introducing a few new initiatives to
improve the overall communication of the project. Partly as an effort to
more closely coordinate development with operator needs, we're moving our
design documents to Gerrit under the stackforge/puppet-openstack_spec
project. This will allow anyone from the community to give high-level and
inline feedback on module design. One of the nice aspects of the Gerrit
review system is that feedback is accompanied with +1, -1, or 0 rankings
that clearly express a reviewer's support of a change. We're also starting
weekly IRC meetings, and we strongly encourage and welcome everyone from
the community to participate. The tentative start date for the IRC meetings
will be Monday, June 2. More details about both the spec project and
meetings will be announced as information is available.
This is just a brief overview of the wide range of topics that we covered
in the brief time that we had. Full notes can be found on the session
Etherpad. The #puppet-openstack IRC channel on freenode is a great place to
speak directly with the puppet-openstack community, and there's almost
always someone online to talk with. The puppet-openstack mailing list [
is the forum to engage in larger discussions about the use and development
of the modules. You should also feel free to reach out directly to me with
Again, thanks to everybody who came to the session. It was valuable to have
the operators and developers in the same room and get a clear view of what
we need to to do to improve the modules in practice.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators