Open Stack

On Sat, Jun 16, 2018 at 3:06 AM, Lars Kellogg-Stedman <lars at redhat.com> 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