<div dir="ltr">I was asked to repost this from the puppet-openstack mailing list. My apologies if you have received this twice.<div><br></div><div>--------<br><div><br></div><div><div>Summary of Atlanta OpenStack Summit Puppet Operators Meetup</div>

<div><br></div><div>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 OpenStack deployments.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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 [<a href="https://groups.google.com/a/puppetlabs.com/forum/#!forum/puppet-openstack">https://groups.google.com/a/puppetlabs.com/forum/#!forum/puppet-openstack</a>] 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 questions.</div>

<div><br></div><div>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. </div>

<div><br></div><div>-Chris</div></div></div></div>