> > 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/
_______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra