<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Emilien,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Emilien Macchi wrote:<br>
> I just noticed we have a second module written by Cody:<br>
> <a href="https://github.com/ody/puppet-rally" rel="noreferrer" target="_blank">https://github.com/ody/puppet-rally</a><br>
><br>
> We might want to collaborate on that.<br>
><br>
<br>
</span>Yeah...I'd actually completely forgotten that existed until Emilien<br>
mentioned it to me in IRC.<br>
<br>
It was my responsibility to deploy rally for our production cloud so I<br>
started down the road of building a rally module that I intended to ship<br>
upstream but things never panned out.  I pretty much ran cookiecutter<br>
and then added the openstack-rally package resource that was dependent<br>
on our internal RPM repository that contained a openstack-rally package<br>
I built myself because one existed no where else.  I never actually ran<br>
the module through Puppet.<br>
<br>
Since we were behind on deployment I put rally on the back burner until<br>
I had something fully functional in pre-production to start running<br>
rally against.  Plus, at that time we were pre-liberty release so no one<br>
was shipping an openstack-rally package which would have made putting<br>
the module I started into the upstream project difficult since it would<br>
be unusable and untestable.  So, instead I focussed on tying off some<br>
other internal things and my OpenStack time was spent working on already<br>
established Puppet OpenStack community items, reviews and CI.<br>
<br>
Now we are in December and Mitaka is in full swing, there are<br>
openstack-rally packages upstream in Mitaka repos, and our internal<br>
pre-production install is fully functional so...I am back to working on<br>
a rally deployment.  I am happy to collaborate on merging/just promoting<br>
one of these modules to upstream.  I do not have a preference for which<br>
one does become upstream; in their current state they probably both need<br>
a fresh run through cookiecutter and msync</blockquote><div><br></div><div>As discussed on IRC, I've started a new puppet-rally module:</div><div><br></div><div><a href="https://github.com/andybotting/puppet-rally">https://github.com/andybotting/puppet-rally</a><br></div></div><br></div><div class="gmail_extra">It's based on a fresh run of cookiecutter/msync and it's fairly complete. There's a few tests in there, but they're failing due to not being able to find an official rally package.</div><div class="gmail_extra"><br></div><div class="gmail_extra">When I'm back at work in the new year, I'll be looking to switch our production system over to this new module to test it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rally has a lot of config options, so I wrote a hacky script to pull all the options from the default rally.conf file and use them in the module. It makes the init.pp params pretty long. I thought an alternative could have been to pass in a hash of override params, but I prefer it this way TBH.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Let me know what you think.</div><div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">Andy</div></div>