[openstack-dev] [puppet] Installing dependent modules in functional testing

Colleen Murphy colleen at gazlene.net
Thu Jun 18 21:24:28 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/b229d350/attachment.html>


More information about the OpenStack-dev mailing list