Open cgol opened 4 years ago
This would also assist with CodePipeline Automation where a CodePipeline runs for the first time and deploys a stack that fails. It needs to be manually deleted before the CodePipeline can run again.
This would also assist with CodePipeline Automation where a CodePipeline runs for the first time and deploys a stack that fails. It needs to be manually deleted before the CodePipeline can run again.
For other readers it may be worth pointing out that you can do this in CodePipeline to have it delete-then-recreate the failed stack within the CodePipeline Action:
Configuration:
ActionMode: REPLACE_ON_FAILURE
However I'd advise caution with that option. CodePipeline will also attempt to delete any stack that is in ROLLBACK_FAILED, which may very well not be ideal if you already have an existing stack you managed to get into a weird state.
To me this enhancement request means just consider ROLLBACK_COMPLETE an update-able state so that you can modify in place without having to delete the empty shell of the stack just to retry.
Usability feature for the CloudFormation Console to allow a Failed Stack to be redeployed with modification, rather than having to Delete / Create. The behaviour should mimic a failed update.
Often when creating a new stack from the console it will pass validation but then fail and roll back for any number of reasons. The user then needs to delete the stack and create a new stack and enter all the options again from scratch.
It would be really useful and quicker to be able to redeploy the failed template - optionally uploading a new stack template or changing one or more parameters or tags. The useful feature would be to retain the parameter values, tags, notification policies etc from the previous failed deployment and not have to reenter them all again.
I understand this can all be readily scripted from the CLI command line, and there is a feature request aws-cloudformation/cfn-language-discussion#60 to be able to accept a parameter value file, but 1) its in non-human friendly JSON, and 2) we also need to enter other values such as tags and stack policies.
When developing a stack in a sandpit its quick and easy to use the console to upload and deploy a simple stack and interactively enter (non-default) values but it can take 3 or 4 or many times before success. If there are a number of parameters and/or tags that need to be entered or overridden each time this process can be frustrating. A Failed Create should behave like a Failed Update and remember all these values and allow a new Template to be uploaded.
Enhancement Request.