In Master, during stack update, the services' config are regenerated by (re)running all container-puppet-{service}. If those containers were created prior to the stack update, they are reused and restarted during the stack update.
Re-running existing container-puppet-{service} is not idempotent, because the very first thing done in those containers is to copy the state of /etc/puppet from the host into the container's /etc. So once the containers are restarted they have an unexpected initial state.
The lack of idempotency is problematic when using upload-puppet-modules. The injection of a puppet module replaces the symlink present under /etc/puppet/modules/ with a real directory. For instance if injecting the tripleo module, one will end up with the following content on the host:
# ls -l /etc/puppet/modules/
[...]
lrwxrwxrwx. 1 root root 42 Aug 19 15:19 tomcat -> /usr/share/openstack-puppet/modules/tomcat
drwxr-xr-x. 10 heat-admin heat-admin 4096 Aug 19 15:13 tripleo
lrwxrwxrwx. 1 root root 43 Aug 19 15:19 vcsrepo -> /usr/share/openstack-puppet/modules/vcsrepo
[...]
As a side effect, when restarting container-puppet-{service}, the script container-puppet.sh will fail to copy the puppet content from the host to the container:
cp: cannot overwrite non-directory '/etc/puppet/modules/tripleo' with directory '/tmp/puppet-etc/modules/tripleo'
This is because the previous puppet content is still present in the container when it is restarted, and since originally /etc/puppet/modules/tripleo was a symlink, it can't be replaced with a real directory.
Fix proposed to branch: master
Review: https:/