Hide Forgot
This update moves the deployed directory from /var/run/heat-config/deployed, which is usually tmpfs, to /var/lib/heat-config/deployed, which allows the deployed state to persist across reboots.
The os-refresh-config script 55-heat-config uses /var/run for the value of it's DEPLOYED_DIR variable. DEPLOYED_DIR is then used to determine what SoftwareDeployments have already been applied or not. The issue is that /var/run is often tmpfs mounted, which means after a reboot and any subsequent os-collect-config metadata changes all the SoftwareDeployemnts are reapplied whether they should be or not.
The permanent fix will be in heat-templates, but if we need a fix which doesn't require a new image we could put a workaround in tripleo-heat-templates which moves existing files from /var/run/heat-config to /var/lib/heat-config and creates a symlink from /var/run/heat-config to /var/lib/heat-config
i think we need an async update to openstack-heat-templates to address this, or at the very least in z3. the package update could have a %post script to do a migration of the existing /var/run/heat-config to a more persistent location steve what are your thoughts on this and when it could get done?
If it is a priority I can do it early next week. As an alternative to %post migration, 55-heat-config could check for old and new paths and self-migrate the next time it is run.
Upstream fix is ready for review, its not obvious to me whether this gets downstream via rebase or rh gerrit.
there's an additional fix needed for this one, so moving back to ON_DEV. the patches are posted (see external ref's).
Unless I am missing something here, then /var/run must not be used at all. on this version: openstack-heat-templates-0-0.8.20150605git.el7ost.noarch and in this file /usr/share/openstack-heat-templates/software-config/heat-container-agent/scripts/55-heat-config lines 27 and 31 point to /var/run anyway.
I re-read it again. If the script is there, moving things after reboot and upgrade works (7.0 to 7.2 and 7.1 to 7.2 works at this time) then this is suffice to say that it did its job and verify this bug.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:2680