Open Stack

>
> We should look for a way to make developing, debugging and testing our
> puppet modules locally easier and more consistent.
> Short of bootstrapping an entire clone of openstack-infra, how do
>

This is pretty much what we do at the moment to maintain our internal
openstack-infra CI pipeline, we're still running a puppet master with a
single control repo (i.e. we're not split into system-config &
project-config yet)

We have a Vagrantfile that allows us to standup a puppet master with our
config & openstack-infra/config & hieradata mounted from local checkouts on
the workstation, this allows us to tweak our private modules directly,
import external modules via modules.env & tweak site.pp directly

we then have further guest vm definitions in our Vagrantfile to match the
host/role that's being worked on (as we're using site.pp, hostnames need to
match entries in site.pp, so we use vagrant-hostmanager to maintain
/etc/hosts across the guest VMs so that when we stand up a guest vm, the
puppet master compiles a catalogue that closely matches production.


> developers currently set up an environment to investigate how a puppet
> module behaves? This brings me to my first question:
> 1) Do we want to find/provide a way to set up a consistent development
> environment?
> Vagrant could be a useful way of providing a consistent development
> environment for those working on infra's puppet modules. This comes up in
> light of https://review.openstack.org/#/c/355273 which was split out from
> a larger change due to debate over any vagrant precedent. This change was
> in turn based upon this documented example of simulating OpenStack Infra
> environments for testing: https://krotscheck.net/2016/06
> /01/how-to-simulate-an-openstack-infra-slave.html
> Currently the only module (that a quick grep found for me) providing a
> vagrant file is puppet-storyboard.
> 2) Is Vagrant a good fit for this? Otherwise should we consider an
> ansible-playbook to bootstrap an environment?
>

I think Vagrant is very useful for this, it provides a decent abstraction
over the various virtualisation systems you may wish to use (virtualbox,
kvm, docker - we're only using virtualbox internally as it's the most
widely supported provider in Vagrant) - setting up the required networking,
mapping filesystems into VMs & managing /etc/hosts on guests & on the host
as required.

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)

[1] https://github.com/puppetlabs/beaker
[2] https://github.com/neillturner/kitchen-puppet & http://kitchen.ci/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160825/fe0f045b/attachment.html>