Fix non-destructive upgrade for deprecated res types in convergence
When a user updates from a deprecated resource type to an
equivalent-but-differently-named one (e.g. from
OS::Heat::SoftwareDeployments to OS::Heat::SoftwareDeploymentGroup), Heat
is supposed to change the type without replacing the resource as it would
normally do when a resource type changes. This was broken in convergence,
because since 45073226752c58d640ea5a59b7e532c022a4939b the new Resource
object we create during the check_resource operation (using the new type's
plugin) is no longer automatically initialised with data from the database
as resources in the legacy path are.
Move the substitution checking to the Resource.load() method, so that it
now returns an instance of the new plugin where allowed. In the actual
update_convergence() method then we need only check that the resource class
is the one we'd expect from the new template, and replace the resource if
not.
We do have a test that is designed to check that this is working, but in it
we didn't compare the physical IDs of the resource that is potentially
getting replaced, but rather the physical IDs of some other resource that
can't possibly get modified (surprise! it doesn't change).
Conflicts:
heat/engine/resource.py
This patch is modified with respect to the one on master, since the
branch does not contain 960f626c2455b77e654aea1d79597fadb91dc894. Thus,
resource_owning_stack.defn is substituted for initial_stk_defn and
curr_stack.defn for latest_stk_defn.
Change-Id: I75778abc303525a71d0a918f7192f00a43c21284
Closes-Bug: #1729439
(cherry picked from commit 93b4551d9a1ff9194b30a079f02db691129c69b0)
Reviewed: https:/ /review. openstack. org/526802 /git.openstack. org/cgit/ openstack/ heat/commit/ ?id=0d005ffcb69 b8c5be3228957f7 dfb8809b811742
Committed: https:/
Submitter: Zuul
Branch: stable/pike
commit 0d005ffcb69b8c5 be3228957f7dfb8 809b811742
Author: Zane Bitter <email address hidden>
Date: Wed Nov 1 18:03:20 2017 -0400
Fix non-destructive upgrade for deprecated res types in convergence
When a user updates from a deprecated resource type to an but-differently -named one (e.g. from :Heat:: SoftwareDeploym ents to OS::Heat: :SoftwareDeploy mentGroup) , Heat 640ea5a59b7e532 c022a4939b the new Resource
equivalent-
OS:
is supposed to change the type without replacing the resource as it would
normally do when a resource type changes. This was broken in convergence,
because since 45073226752c58d
object we create during the check_resource operation (using the new type's
plugin) is no longer automatically initialised with data from the database
as resources in the legacy path are.
Move the substitution checking to the Resource.load() method, so that it convergence( ) method then we need only check that the resource class
now returns an instance of the new plugin where allowed. In the actual
update_
is the one we'd expect from the new template, and replace the resource if
not.
We do have a test that is designed to check that this is working, but in it
we didn't compare the physical IDs of the resource that is potentially
getting replaced, but rather the physical IDs of some other resource that
can't possibly get modified (surprise! it doesn't change).
Conflicts: engine/ resource. py
heat/
This patch is modified with respect to the one on master, since the e654aea1d79597f adb91dc894. Thus, owning_ stack.defn is substituted for initial_stk_defn and
branch does not contain 960f626c2455b77
resource_
curr_stack.defn for latest_stk_defn.
Change-Id: I75778abc303525 a71d0a918f7192f 00a43c21284 94b30a079f02db6 91129c69b0)
Closes-Bug: #1729439
(cherry picked from commit 93b4551d9a1ff91