Open Stack

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