You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When launching a stack group, some stacks might fail and end up in the status `ROLLBACK_COMPLETE". Currently, sceptre would interpret this as a success, goes on with the deployment and tries to access outputs from the rollbacked stack. Furthermore, I often overlook that something failed and just assume everything worked. I think, it should be more prominent.
Now, a stack can end up in ROLLBACK_COMPLETE when being created the first time or when being updated. Therefore, the referenced output might or might not be defined. So, the dependent stack could actually fail. And if it does not fail, it is questionable, whether this is the desired result. Some parts of my deployment actually failed, and I would rather fail early than continuing until the end.
It might make sense to add a command-line option to enable/disable this behaviour, so you can explicitly ignore rollbacks if you want to.
The text was updated successfully, but these errors were encountered:
Launch should delete then create the stack if it encounters ROLLBACK_COMPLETE can you confirm the final state of the stack?
Indeed, launch does delete and tries to create the stack correctly. That works fine. The problem is if a dependent stack is in ROLLBACK_COMPLETE.
Example: There are two stacks A and B. Stack A depends on Stack B. If I launch both, first Stack B is launched. Now if Stack B fails, it will eventually end up in ROLLBACK_COMPLETE. Then sceptre still tries to start Stack A, eventhough Stack B could not be created (or updated).
When launching a stack group, some stacks might fail and end up in the status `ROLLBACK_COMPLETE". Currently, sceptre would interpret this as a success, goes on with the deployment and tries to access outputs from the rollbacked stack. Furthermore, I often overlook that something failed and just assume everything worked. I think, it should be more prominent.
Now, a stack can end up in
ROLLBACK_COMPLETE
when being created the first time or when being updated. Therefore, the referenced output might or might not be defined. So, the dependent stack could actually fail. And if it does not fail, it is questionable, whether this is the desired result. Some parts of my deployment actually failed, and I would rather fail early than continuing until the end.It might make sense to add a command-line option to enable/disable this behaviour, so you can explicitly ignore rollbacks if you want to.
The text was updated successfully, but these errors were encountered: