-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
provider/aws: Handle all kinds of CloudFormation stack failures #5606
provider/aws: Handle all kinds of CloudFormation stack failures #5606
Conversation
I have received response from AWS support - there seems to be a fairly clean (yet slightly confusing) solution. If Stack ID (instead of stack name) is passed as a value of an argument I will update the PR soon. |
ac6f6b8
to
3599822
Compare
Just encountered this issue, glad to see it's already been identified and in the process of being addressed. Anything I can do to help drive this forward? Would be good to get this out. |
@radeksimko is this is a place to test right now? |
c31ef5a
to
4e90fc6
Compare
- Use ID instead of stack name per AWS' advice - Query failures/errors *after* the stack has reached target state
4e90fc6
to
58d5b88
Compare
@stack72 This is now finally ready for review. Sorry for such a long delay. Test planhttps://gist.github.com/radeksimko/961c544ab114b72c665392ed4b2ce786 |
Hi @radeksimko Been through this tonight and it looks good to me :) P. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
This fixes #5559 (specifically cb4c2a9) and attempts to fix #5487 (It is fixing an unreported bug which became clear as part of that issue).
Explanation
I'm treating this as WIP because I have asked AWS support for advice on how to catch reasons behind deleted stacks when user specifies
OnFailure=DELETE
reliably and I may modify this PR based on their response.In worst case I'll most likely send another PR to introduce something like
MaxRetry
intoresource.StateChangeConf
which would allow me locally reducing this from hard-coded 10 seconds (if it's reached via exponential backoff) to 1 second (or something like that) at the risk of potentially being throttled by API limits, but reducing the risk of missing events that contain reasons for stack deletion.In theory you could say that CloudFormation is slow enough that going from
CREATE_IN_PROGRESS
overDELETE_IN_PROGRESS
to be gone should take more than 10 seconds, but it may not always be the case.Test plan
make testacc TEST=./builtin/providers/aws TESTARGS='-run=AWSCloudFormation'