tree 4a54ec28576db37376f8176f0b2a9c3e391286dc
parent ee582d9169eae3273114cc554c4b425418508573
author Zane Bitter <zbitter@redhat.com> 1473727912 -0400
committer Zane Bitter <zbitter@redhat.com> 1473727912 -0400

Copy correct definition to the backup stack

We were using the definition of the existing resource, immediately after
updating it in place, to copy to the backup stack. This turns out to be
incorrect, because the definition of the new resource is only copied to the
existing resource if it was actually updated. It doesn't follow that the
existing resource's definition must be the same, because it's actually the
frozen definition (using the stored property values from the DB) that's
compared with the new definition when deciding to update. The existing
definition might well be rubbish if a previous update is failed, because it
does not get updated in the existing template after the resource is updated
in place. This caused bug 1622795 when combined with the new conditionals
feature.

We were also using the wrong template to do the parsing in both cases: when
updating in-place we are passing the new definition, but we were reparsing
using the existing template. And we were effectively doing the same when
creating a new resource, because we accessed the template through the new
resource only *after* it had been moved to the existing stack. In both
cases the correct code would have been:

  definition = new_res.t.reparse(self.previous_stack,
                                 new_res.stack.t)

However, there's no actual need to reparse the resource definitions before
passing them to Template.add_resource(), because that method immediately
calls render_hot() to get back to the unparsed definition anyway. So just
don't bother. These issues have been requiring us up until now to cache the
conditionals from the new_stack in the Template, to prevent the reparsing
from looking at the wrong set of conditionals. This change relieves us of
that restriction.

Finally, change the debug error messages to distinguish this case (copying
a resource definition into the backup template) from "backing up" a
resource (moving an actual physical resource into the backup stack).

Change-Id: I7be92f2e1b812c23fa52d87c18c7f22f1be94446
Closes-Bug: #1622795