On 06/18/2015 05:24 PM, Colleen Murphy 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).
For the reasons mentioned in the etherpad, big +1 on idea #1. It will also help a lot in bringing consistent our tests since we will finally make sure to use the same module versions. > 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. +1 for puppet-openstack-integration > Opening this up for thoughts on this implementation proposal and the > repo name. > > Colleen Thanks a lot for this work, I see a lot of interest in what you're doing to have real cross-project functional testing and also think about how to test upgrades (a grenade-like) in the future. > [1] https://etherpad.openstack.org/p/puppet-git-dependencies > [2] https://review.openstack.org/#/c/190839 > [3] https://github.com/cmurphy/puppet-openstack-dependencies > > > __________________________________________________________________________ > 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 > -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
