Open Stack

On Tue, Jun 19, 2018 at 02:18:38PM +0100, Steven Hardy wrote:
> Is this the same issue Carlos is trying to fix via
> https://review.openstack.org/#/c/494517/ ?

That solves part of the problem, but it's not a complete solution.
In particular, it doesn't solve the problem that bit me: if you're
changing puppet providers (e.g., replacing
provider/keystone_config/ini_setting.rb with
provider/keystone_config/openstackconfig.rb), you still have the old
provider sitting around causing problems because unpacking a tarball
only *adds* files.

> Yeah I think we've never seen this because normally the
> /etc/puppet/modules tarball overwrites the symlink, effectively giving
> you a new tree (the first time round at least).

But it doesn't, and that's the unexpected problem: if you replace the
/etc/puppet/modules/keystone symlink with a directory, then
/usr/share/openstack-puppet/modules/keystone is still there, and while
the manifests won't be used, the contents of the lib/ directory will
still be active.

> Probably we could add something to the script to enable a forced
> cleanup each update:
> 
> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/deploy-artifacts.sh#L9

We could:

(a) unpack the replacement puppet modules into a temporary location,
  then

(b) for each module; rm -rf the target directory and then copy it into
  place

But! This would require deploy_artifacts.sh to know that it was
unpacking puppet modules rather than a generic tarball.

> This would have to be optional, so we could add something like a
> DeployArtifactsCleanupDirs parameter perhaps?

If we went with the above, sure.

> One more thought which just occurred to me - we could add support for
> a git checkout/pull to the script?

Reiterating our conversion in #tripleo, I think rather than adding a
bunch of specific functionality to the DeployArtifacts feature, it
would make more sense to add the ability to include some sort of
user-defined pre/post tasks, either as shell scripts or as ansible
playbooks or something.

On the other hand, I like your suggestion of just ditching
DeployArtifacts for a new composable service that defines
host_prep_tasks (or re-implenting DeployArtifacts as a composable
service), so I'm going to look at that as a possible alternative to
what I'm currently doing.

-- 
Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {irc,twitter,github}
http://blog.oddbit.com/                |