SoftwareDeployments -> SoftwareDeploymentGroup update is destructive

Bug #1528958 reported by Steven Hardy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
High
Rico Lin

Bug Description

If you attempt to update a stack containing OS::Heat::SoftwareDeployments resources, so it uses the new non-deprecated OS::Heat::SoftwareDeploymentGroup type instead, it deletes the group, and all of the deployments.

This means that any deployment "actions" property will be misinterpreted, e.g if you have actions: CREATE, all the deployments will re-run on the update, even though it's an update, not a create.

We need a way to ensure the update updates the existing resource in-place, without deleting the entire nested stack containing all the Deployment resources.

Changed in heat:
milestone: none → mitaka-2
Rico Lin (rico-lin)
Changed in heat:
assignee: nobody → Rico Lin (rico-lin)
Steven Hardy (shardy)
Changed in heat:
importance: Undecided → High
Changed in heat:
milestone: mitaka-2 → mitaka-3
Revision history for this message
Steven Hardy (shardy) wrote :

Rico - are you looking at this or can I go ahead and post a patch myself?

Revision history for this message
Rico Lin (rico-lin) wrote :

I'm looking at this patch right now, but not yet start hacking. Feel free to post any patch you wante. :)

Revision history for this message
Rico Lin (rico-lin) wrote :

Start hacking now, still feel free to take over or otherwise :)

Changed in heat:
status: New → In Progress
Revision history for this message
Rico Lin (rico-lin) wrote :
Rabi Mishra (rabi)
Changed in heat:
milestone: mitaka-3 → mitaka-rc1
Changed in heat:
milestone: mitaka-rc1 → newton-1
Rabi Mishra (rabi)
Changed in heat:
milestone: newton-1 → newton-2
Thomas Herve (therve)
Changed in heat:
milestone: newton-2 → ongoing
milestone: ongoing → newton-3
Changed in heat:
assignee: Rico Lin (rico-lin) → Zane Bitter (zaneb)
Thomas Herve (therve)
Changed in heat:
milestone: newton-3 → newton-rc1
Zane Bitter (zaneb)
Changed in heat:
assignee: Zane Bitter (zaneb) → Rico Lin (rico-lin)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (master)

Reviewed: https://review.openstack.org/280201
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=3aeaefc29f27b7e55a0e646b39a5522fb11ccf6c
Submitter: Jenkins
Branch: master

commit 3aeaefc29f27b7e55a0e646b39a5522fb11ccf6c
Author: ricolin <email address hidden>
Date: Sun Apr 3 17:34:52 2016 +0800

    Non-destructive upgrade for deprecated resources

    If you attempt to update a stack containing
    OS::Heat::SoftwareDeployments resources, so it uses the new
    non-deprecated OS::Heat::SoftwareDeploymentGroup type instead, it
    deletes the group, and all of the deployments.

    This means that any deployment "actions" property will be
    misinterpreted, e.g if you have actions: CREATE, all the deployments
    will re-run on the update, even though it's an update, not a create.

    This issue exists on all deprecated resoruces, when we trying to upgrade
    to new version of it by update.

    This patch fix above update issue by check if resoruce was deprecated
    and been update by replacing resource (which is the parent class of
    existing resource).

    Change-Id: Ib7880120a90c4497a7ceea53eee55c220a28d14e
    Closes-Bug: #1528958

Changed in heat:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/368275

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/heat 7.0.0.0rc1

This issue was fixed in the openstack/heat 7.0.0.0rc1 release candidate.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on heat (stable/mitaka)

Change abandoned by Rico Lin (<email address hidden>) on branch: stable/mitaka
Review: https://review.openstack.org/368275

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.