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 <[email protected]> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
