reset_stack_status does nothing if lock engine_id is None

[Steve Baker]

Having a stack which is wedged UPDATE_IN_PROGRESS due to another bug, restarting heat-engine should have resulted in the stack being reset to UPDATE_FAILED. However the reset was skipped because the lock engine_id was None:
http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/service.py#n1820

I would propose this check be removed.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/243358

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/246643

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/246702

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/243358
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=44b2f0965dd329cf45a151705b0648819acff8c7
Submitter: Jenkins
Branch: master

commit 44b2f0965dd329cf45a151705b0648819acff8c7
Author: Steve Baker <email address hidden>
Date: Tue Nov 10 13:09:10 2015 +1300

    Reset stack status even when lock engine_id is None

    Having a stack which is wedged UPDATE_IN_PROGRESS due to another bug,
    restarting heat-engine should have resulted in the stack being reset to
    UPDATE_FAILED. However the reset was skipped because the lock engine_id
    was None.

    This change removes the engine_id check since it is possible in practice
    for an UPDATE_IN_PROGRESS stack to not be locked.

    Since it is possible for the stack to change state in the unlocked
    window, a check is added that the stack is still IN_PROGRESS before the
    reset is performed.

    Change-Id: I1739ccbdf75af35aac5be16b99200975df58b8e2
    Closes-Bug: #1514615

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/246643
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=9688aa6abab8f87e6b542faebe6381ce74676802
Submitter: Jenkins
Branch: stable/liberty

commit 9688aa6abab8f87e6b542faebe6381ce74676802
Author: Steve Baker <email address hidden>
Date: Tue Nov 10 13:09:10 2015 +1300

    Reset stack status even when lock engine_id is None

    Having a stack which is wedged UPDATE_IN_PROGRESS due to another bug,
    restarting heat-engine should have resulted in the stack being reset to
    UPDATE_FAILED. However the reset was skipped because the lock engine_id
    was None.

    This change removes the engine_id check since it is possible in practice
    for an UPDATE_IN_PROGRESS stack to not be locked.

    Since it is possible for the stack to change state in the unlocked
    window, a check is added that the stack is still IN_PROGRESS before the
    reset is performed.

    Change-Id: I1739ccbdf75af35aac5be16b99200975df58b8e2
    Closes-Bug: #1514615
    (cherry picked from commit 44b2f0965dd329cf45a151705b0648819acff8c7)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/246702
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=20f6676c8b8db371c7264d3c3c9510640a896a55
Submitter: Jenkins
Branch: stable/kilo

commit 20f6676c8b8db371c7264d3c3c9510640a896a55
Author: Steve Baker <email address hidden>
Date: Tue Nov 10 13:09:10 2015 +1300

    Reset stack status even when lock engine_id is None

    Having a stack which is wedged UPDATE_IN_PROGRESS due to another bug,
    restarting heat-engine should have resulted in the stack being reset to
    UPDATE_FAILED. However the reset was skipped because the lock engine_id
    was None.

    This change removes the engine_id check since it is possible in practice
    for an UPDATE_IN_PROGRESS stack to not be locked.

    Since it is possible for the stack to change state in the unlocked
    window, a check is added that the stack is still IN_PROGRESS before the
    reset is performed.

    Change-Id: I1739ccbdf75af35aac5be16b99200975df58b8e2
    Closes-Bug: #1514615
    (cherry picked from commit 44b2f0965dd329cf45a151705b0648819acff8c7)

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/heat 6.0.0.0b1 development milestone.

[Steve Baker (steve-stevebaker)]

Reopening for Kilo, the thread_lock method needs a stack_id in Kilo but not in later releases

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/253278

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/253278
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=f64cefa628fc061953c38a4c8f0e61e40eab6d6e
Submitter: Jenkins
Branch: stable/kilo

commit f64cefa628fc061953c38a4c8f0e61e40eab6d6e
Author: Steve Baker <email address hidden>
Date: Fri Dec 4 13:05:27 2015 +1300

    reset_stack_status thread_lock needs stack_id

    The initial backport of I1739ccbdf75af35aac5be16b99200975df58b8e2 failed
    to take into account the different method arguments required by the
    thread_lock method, so reset_stack_status doesn't work without this
    change.

    Change-Id: Id11cf0c7d651433cb8331a20552435fbbf822f92
    Closes-Bug: #1514615

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/heat 5.0.1 release.