Make check_active name more generic

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

Bug Description

As mentioned in https://review.openstack.org/#/c/28561/1/heat/engine/resources/wait_condition.py

I think we need to consider revising the check_active interface to make it more generic - I've been running into issues trying to use the same check_active pattern for non-active transistions, e.g stack-suspend without adding more check_foo functions to the plugin API

I think it would be better if we had check_status(self, thing_checking_status, status_we_want), then we can reuse the existing resource statuses, so we could do something like (in resource.py):

while not self.check_status(create_data, self.CREATE_COMPLETE):
    yield

The advantages of this:

    One check interface function in the plugin API, should be more flexible and less fragile than an expanding list of check_foo functions?
    Aligns the top-level states we're checking for with the actual state of the resource (e.g self.CREATE_COMPLETE, not active/complete/whatever), which makes more sense at the resource-plugin-api level, because "active" is really an artefact of the instance "CREATE_COMPLETE" status evaluation, what we're really polling for varies depending on the resource, and all we want to know is are we in a state ready to declare CREATE_COMPLETE (or some other state, such as UPDATE_COMPLETE, DELETE_COMPLETE, and soon SUSPEND_COMPLETE)

Steven Hardy (shardy)
Changed in heat:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Steven Hardy (shardy)
milestone: none → havana-1
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/28781

Changed in heat:
status: Triaged → In Progress
Revision history for this message
Steven Hardy (shardy) wrote : Re: Make check_active interface more generic

After discussion with zaneb on IRC, we've agreed to keep the existing interface, but rename the check_active to check_create_complete, then we'll add check_suspend_complete etc.

This will fix the problem of aligning the check_foo functions with the state we are checking for, and mean that resource implementations must explicitly implement support for the state transition we are attempting.

Revision history for this message
Steven Hardy (shardy) wrote :

Changing title from "Make check_active interface more generic" to "Make check_active name more generic"

summary: - Make check_active interface more generic
+ Make check_active name more generic
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/28948

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

Reviewed: https://review.openstack.org/28948
Committed: http://github.com/openstack/heat/commit/8026858af59c2a0d886881ffaf73c6d2cde39db3
Submitter: Jenkins
Branch: master

commit 8026858af59c2a0d886881ffaf73c6d2cde39db3
Author: Steven Hardy <email address hidden>
Date: Mon May 13 14:45:56 2013 +0100

    engine : rename check_active to make it more generic

    Rename check_active to check_create_complete, since "active" is
    really a detail of Instance state, and so it seems wrong for other
    resources which take a long time to create but are not Instance
    based (e.g WaitConditions). This change will also allow us to
    align other stack "state check" functions with the state we're
    checking for in a consistent way (e.g check_delete_complete etc)

    Fixes bug #1178591

    Change-Id: I55a824e6ba3de87cedd0b844e7f4e1294917533a

Changed in heat:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in heat:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
milestone: havana-1 → 2013.2
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.