mark-unhealthy by physical resource ID

Bug #1635295 reported by Zane Bitter
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
Wishlist
Zane Bitter

Bug Description

The resource mark-unhealthy command identifies the resource to be marked unhealthy by stack ID and resource name. This is particularly convenient for a user marking a resource unhealthy manually.

However, when a script or workflow is marking a resource unhealthy (e.g. based on an alarm), it would be more convenient to specify the physical resource ID. Not only would that save looking up the resource name, but it would avoid a race condition that could occur where continued problems with the old resource could end up marking the replacement as unhealthy.

To avoid any race, we'd need to atomically look up a resource by physical ID (we already have code to do this) and mark it as unhealthy.

Tags: spec-lite
Changed in heat:
assignee: nobody → Tanvir Talukder (tanvirt16)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (master)

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

Changed in heat:
status: Triaged → In Progress
Rabi Mishra (rabi)
Changed in heat:
milestone: ocata-1 → ocata-2
Changed in heat:
assignee: Tanvir Talukder (tanvirt16) → Zane Bitter (zaneb)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (master)

Reviewed: https://review.openstack.org/395124
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=4e465402d051e5906241c57861fdc579e1d767c6
Submitter: Jenkins
Branch: master

commit 4e465402d051e5906241c57861fdc579e1d767c6
Author: Tanvir Talukder <email address hidden>
Date: Mon Dec 5 14:58:20 2016 -0500

    Allow mark-unhealthy by physical resource ID

    If the name passed into mark-unhealthy is not a valid resource name,
    check if it is a valid resource id and retrieve the resource via id
    instead of name.

    Change-Id: Ie28ed102665b2c6379d1f55b7a02b76d05e38ddd
    Co-Authored-By: Zane Bitter <email address hidden>
    Closes-Bug: #1635295

Changed in heat:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/heat 8.0.0.0b2

This issue was fixed in the openstack/heat 8.0.0.0b2 development milestone.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to heat (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/419127

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to heat (master)

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

commit d6f6bfc2e6b86cf85c07c3407cd2a2d97faf88a9
Author: Zane Bitter <email address hidden>
Date: Wed Jan 11 11:41:45 2017 -0500

    Mark nested stacks unhealthy by refid

    Previously, we added the ability to mark a resource unhealthy using its
    physical resource ID. This poses a difficulty for a template resource - the
    can substitute the result of get_resource with the ID of a resource inside
    the nested stack by providing an output named "OS::stack_id". However, the
    physical_resource_id of the resource stored in the database is the UUID of
    the nested stack, and thus the template resource will not be found when
    marking a resource unhealthy using the ID returned from get_resource.

    This particularly shows up when using a scaling group where the members are
    defined by a template rather than a native resource type.

    Solve this by falling back to Stack.resource_by_refid() if we can't find
    the resource in the database. This iterates through all of the resources in
    the stack and finds one where the output of get_resource matches.

    Change-Id: Ia332af68123c3a43a581c0bf7899371bbe043e0d
    Related-Bug: #1635295

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.