<div dir="ltr">(sorry, mail client failure)<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 4:59 PM, Joshua Hesketh <span dir="ltr"><<a href="mailto:joshua.hesketh@gmail.com" target="_blank">joshua.hesketh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 1:31 AM, Simon McCartney <span dir="ltr"><<a href="mailto:simon@mccartney.ie" target="_blank">simon@mccartney.ie</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><div style="font-size:13px"><br></div><div style="font-size:13px"><snip><span style="font-size:small"> </span></div></span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><div class="gmail_extra"><span><div style="font-size:13px">However, I'm not sure Vagrant provides a good solution for testing puppet modules in isolation (I think it's great for the system-config/project-config scenario, where you want to see how applying the full set of required puppet modules on to an empty VM provides a working system), it's harder to test standing up zuul without also setting up a few other components, so puppet-zuul (for example) may not take advantage of Vagrant directly, but may benefit from beaker[1] or test-kitchen[2] work (I think that conversation has happened before but I wasn't directly involved at the time)</div><div style="font-size:13px"><br></div></span></div></div></span></blockquote></div><br></div></div></blockquote><div><br></div><div> So I think this is the interesting part for vagrant. The infra bootstrapping will install other components (as mentioned) which is useful when you want to develop on something intended for OpenStack's infra. However if we want the puppet modules to be more generic and used outside of infra's use case, is this sufficient or should we look towards something more generic (such as vagrant)?</div><div><br></div><div>I'm not really sure how this would look as modules may have complicated inter-dependencies or assumptions about the environment/machine. How do other puppet developers do their modules upstream?</div><div><br></div><div>Cheers,<br>Josh</div></div><br></div></div>