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

Emilien Macchi emilien at redhat.com
Thu Jun 18 22:11:52 UTC 2015

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/39dec0f3/attachment.pgp>

More information about the OpenStack-dev mailing list