On 19.6.2018 16:29, Lars Kellogg-Stedman wrote:
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.
For the puppet modules specifically, we might also add another
directory+mount into the docker-puppet container, which would be blank
by default (unlike the existing, already populated /etc/puppet and
/usr/share/openstack-puppet/modules). And we'd put that directory at the
very start of modulepath. Then i *think* puppet would use a particular
module from that dir *only*, not merge the contents with the rest of
modulepath, so stale files in /etc/... or /usr/share/... wouldn't matter
(didn't test it though). That should get us around the "tgz only adds
files" problem without any rm -rf.
The above is somewhat of an orthogonal suggestion to the composable
service approach, they would work well alongside i think. (And +1 on
"DeployArtifacts as composable service" as something worth investigating
/ implementing.)
Jirka
__________________________________________________________________________
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
