I've been working on a series of patches to enable support for keystone federation in tripleo. I've been making good use of the DeployArtifacts support for testing puppet modules...until today.
I have some patches that teach puppet-keystone about multi-valued configuration options (like trusted_dashboard). They replace the keystone_config provider (and corresponding type) with ones that work with the 'openstackconfig' provider (instead of ini_settings). These work great when I test them in isolation, but whenever I ran them as part of an "overcloud deploy" I would get erroneous output. After digging through the various layers I found myself looking at docker-puppet.py [1], which ultimately ends up calling puppet like this: puppet apply ... --modulepath=/etc/puppet/modules:/usr/share/openstack-puppet/modules ... It's that --modulepath argument that's the culprit. DeployArtifacts (when using the upload-puppet-modules script) works by replacing the symlinks in /etc/puppet/modules with the directories from your upload directory. Even though the 'keystone' module in /etc/puppet/modules takes precedence when doing something like 'include ::keystone', *all the providers and types* in lib/puppet/* in /usr/share/openstack-puppet/modules will be activated. So in this case -- in which I've replaced the keystone_config provider -- we get the old ini_settings provider, and I don't get the output that I expect. The quickest workaround is to generate the tarball by hand and map the modules onto /usr/share/openstack-puppet/modules... tar -cz -f patches/puppet-modules.tar.gz \ --transform "s|patches/puppet-modules|usr/share/openstack-puppet/modules|" \ patches/puppet-modules ...and then use upload-swift-artifacts: upload-swift-artifacts -f patches/puppet-modules.tar.gz Done this way, I get the output I expect. [1]: https://github.com/openstack/tripleo-heat-templates/blob/master/docker/docker-puppet.py -- Lars Kellogg-Stedman <l...@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | __________________________________________________________________________ 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