On Thu, Jun 18, 2015 at 2:24 PM, Colleen Murphy <coll...@gazlene.net> wrote:
> Now that we have the basic beaker-rspec framework set up in the modules > and working in infra's CI, we need to start making our testing aware of > Zuul dependencies. The infra team is facing similar challenges so it would > be nice to work together on this. Discussions with jeblair and nibalizer > have resulted in an etherpad[1] with some possible solutions, where Idea 1 > seems to be the most mutually beneficial. The idea is to have JJB prepare > the node prior to testing, and to share an install script for when > developers are running tests locally. This would install all of our modules > and all their dependencies, not just the specific ones needed by one > particular module, because this makes it easier to share a common thing > between modules and frees us from worrying about implicit dependencies > (modules needed to set up infrastructure that aren't listed explicitly in > metadata.json) and transitive dependencies (dependencies of co-gated > modules). > > I've written a possible implementation using r10k with a Puppetfile[2][3]. > R10k is generally promoted as the preferred way to manage puppet > environments so it makes sense to use it in our tests. It also gives us the > benefit of having a commonly defined Puppetfile that lays out versions of > modules that are guaranteed to work together. This POC script is also using > zuul-cloner to clone dependencies from Zuul if running in a CI environment. > This part could be extracted out into the node prep stage later, which > would be more in line with Idea 1 in the etherpad, but it's hard to test > that functionality at this early stage. > > I'd like to create a new repo to hold this install script and Puppetfile. > This repo could also eventually become a home for integration testing > material, like a kind of devstack. I suggest we call it > openstack/puppet-openstack-testing or > openstack/puppet-openstack-integration. I would like to avoid calling it > anything that could imply that it should be used as a composition module. > > Opening this up for thoughts on this implementation proposal and the repo > name. > > Colleen > > [1] https://etherpad.openstack.org/p/puppet-git-dependencies > [2] https://review.openstack.org/#/c/190839 > [3] https://github.com/cmurphy/puppet-openstack-dependencies > I proposed a patch to create a new repo for this, see https://review.openstack.org/194287 Colleen
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
