On Tue, Jun 19, 2018 at 9:17 AM, Jiří Stránský <ji...@redhat.com> wrote: > 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. >
So the described problem is only a problem with puppet facts and providers as they all get loaded from the entire module path. Normal puppet classes are less conflict-y because it takes the first it finds and stops. > 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.) > -1 to more services. We take a Heat time penalty for each new composable service we add and in this case I don't think this should be a service itself. I think for this case, it would be better suited as a host prep task than a defined service. Providing a way for users to define external host prep tasks might make more sense. Thanks, -Alex > 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 __________________________________________________________________________ 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