On Sat, Jun 16, 2018 at 3:06 AM, Lars Kellogg-Stedman <[email protected]> wrote: > 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.
Is this the same issue Carlos is trying to fix via https://review.openstack.org/#/c/494517/ ? I think there was some confusion on that patch around the underlying problem, but I think your explanation here helps, e.g the problem is you can conceivably end up with a mix of old/new modules? Thanks, Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
