relaunch failed stack

Registered by Nikunj Aggarwal

Summary:
This blueprint targets the re-launching of the failed stack with its existing template in the Horizon dashboard.

Motivation:
If user don't want to change the stack template instead user wishes to re-launch the creation of failed stack using the template used for the failed stack with or without same user data.

Example: If a user have more than one networks and tries to launch a stack without specifying which network to use during stack creation, stack will fail. The reason for the stack creation failure will be multiple networks and not specifying which network to use.
So, after getting creation of stack failed, users chooses to deletes the extra networks from their environment and retains only one network. After the above step, if user wishes to re-launch the failed stack after taking the appropriate steps with the existing template of the failed stack. But user can't re-launch the failed stack due to absence of this feature and have to go through the trouble of creating a new stack or changing the stack template which sometimes user wishes to avoid.

Sometimes user might give an image name or flavor name or any other value wrong and which will in turn fail the stack creation. In those cases also this feature will be useful instead re-creating whole thing from the scratch again.

Just imagine user is launching a stack with 10 resources and using 10 different images and as user data providing the flavor details, key value and image name for those 10 different resources. If stack creation fails because user did some typo during entering the user data or due to some other scenario than without this feature user have to recreate the stack again and enter the user data for those 10 resources again. But which this feature a click or just fix in that typo will be enough to resume the stack creation.

Also when user is launching a stack containing large number of resources and if it fails, creating a new stack will be time consuming.

Description:
As mentioned in the motivation, this feature targets re-launch of the failed stacks with the existing template of the failed stack with or different user data. It gives flexibility to the end-user to re-launch a failed stack without going through the trouble of recreating the stack again.

As of now there is no direct Heat API which can re-launch a failed stack but there are steps which can be followed to re-launch a failed stack successfully. So, from the Heat API side, we have to follow these steps:

a) Get the data from the Heat using "stack_show" API and store the user data in a variable for the specific template
b) Use Heat “abandon” API to abandon the stack, also this API call returns the stack template.
c) Use the “adopt” Heat API for re-launching the stack
d) Pass the stack template obtained in step (b) and the user data in the step (a) to the “adopt” Heat API

This approach will take care of the template and the user data for re-launch of the stack and will not require the user intervention only if user wishes to change user data during re-launch of stack.

This approach might look a work around but these are the actual steps can be taken from the CLI to re-launch a failed stack.

As we follow the above mentioned steps, the abandon and adopt HEAT API calls will not create each and every resource for the scratch. The adopt Heat API will see which resources are failed and will try to create them only. So, this approach is not time consuming as re-creating the stack from the scratch or updating the template.

UX:
In the UX side, it will only add an option in row actions of the stack table. Upon clicking the re-launch option in the stack table, user can decide to change the user data before re-launching the stack creation.

In UX we will not be needing any new UX change to be implemented in the Horizon. For this feature all the UX elements we need are already present and implemented in the Horizon. This feature will be like updating an uploaded image in the Horizon’s image panel.

Testing:
As mentioned above this feature will be found under Orchestration ->stacks. On the stacks page, this feature can be found in the row actions of the stack table.

For testing this feature:

a) Create an additional network
b) Then this HEAT template[https://github.com/openstack/heat-templates/blob/master/hot/hello_world.yaml] or any other template (which doesn’t specifies which network to use) can be used to launch the stack.
c) Stack creation will fail due to the presence of multiple networks.
d) After stack failure, delete the newly created network
e) Then use the re-launch stack feature and it should create a successful stack.
f) If re-launch stack feature creates a successful stack that mean this feature is working.

For further more testing, create a stack and make sure it fails. Then find outs what is the reason for failure and resolve the failure reason. After that use this feature for re-launching the stack again.

Outside Dependencies:
N/A

Requirements Update Required:
N/A

Doc Impact:
N/A

Blueprint information

Status:
Complete
Approver:
David Lyle
Priority:
Medium
Drafter:
Nikunj Aggarwal
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
David Lyle

Related branches

Sprints

Whiteboard

[david-lyle | Nov 10, 2014] Question regarding the flow... So clicking "relaunch" would bring up the create stack dialog, pre-populated? Not sure I'm understanding where the user is correcting the errors.

Also, how does the user know which parameters to fix?

[nikunj2512 | Oct 30, 2014] Yes, when user clicks the "relaunch", it will bring up the form with pre-populated values which user gave during stack creation. And these per-populated values can be edited by the user, if they wish to change the value of any parameter.

Yes, if Heat fails due to a parameter error than heat reports do to which parameter it failed. In the heat's stack-show api, it will tell the reason.

[david-lyle | 2016-06-15] This seems like a good addition, but doesn't have an owner. So setting a priority but not assigning to a release until there is an owner.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.