<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 8, 2016 at 2:42 PM, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi folks,<br>
<br>
Over the last months we've been creating more and more modules [1] [2]<br>
and I would like to take the opportunity to continue some discussion<br>
we had during the last Summits about the quality of our modules.<br>
<br>
[1] octavia, vitrage, ec2api, tacker, watcher, congress, magnum,<br>
mistral, zaqar, etc.<br>
[2] by the end of Newton, we'll have ~ 33 Puppet modules !<br>
<br>
Announce your work<br>
As a reminder, we have defined a process when adding new modules:<br>
<a href="http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html</a><br>
This process is really helpful to scale our project and easily add modules.<br>
If you're about to start a new module, I suggest you to start this<br>
process and avoid to start it on your personal github, because you'll<br>
loose the valuable community review on your work.<br>
<br>
Iterate<br>
I've noticed some folks pushing 3000 LOC in Gerrit when adding the<br>
bits for new Puppet modules (after the first cookiecutter init).<br>
That's IMHO bad, because it makes reviews harder, slower and expose<br>
the risk of missing something during the review process. Please write<br>
modules bits by bits.<br>
Example: start with init.pp for common bits, then api.pp, etc.<br>
For each bit, add its unit tests & functional tests (beaker). It will<br>
allow us to write modules with good design, good tests and good code<br>
in general.<br>
<br>
Write tests<br>
A good Puppet module is one that we can use to successfully deploy an<br>
OpenStack service. For that, please add beaker tests when you're<br>
initiating a module. Not at the end of your work, but for every new<br>
class or feature.<br>
It helps to easily detect issues that we'll have when running Puppet<br>
catalog and quickly fix it. It also helps community to report feedback<br>
on packaging, Tempest or detect issues in our libraries.<br>
If you're not familiar with beaker, you'll see in existing modules<br>
that there is nothing complicated, we basically write a manifest that<br>
will deploy the service.<br>
<br>
<br>
If you're new in this process, please join our IRC channel on freenode<br>
#puppet-openstack and don't hesitate to poke us.<br>
<br>
Any feedback / comment is highly welcome,<br>
Thanks,<br>
<span class=""><font color="#888888">--<br>
Emilien Macchi<br><br></font></span></blockquote><div><br></div><div>I like the ideas, especially about 3000 line commits. I started with your tips and added them to the docs:</div><div><br></div><div> <a href="https://review.openstack.org/329253">https://review.openstack.org/329253</a> Document Emilien's tips for new modules </div></div><br></div></div>