Skip to content
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

Fix Elastic Beanstalk dependency issue causing delete failure. #2080

Conversation

gerph
Copy link

@gerph gerph commented Oct 27, 2017

Commonly we were seeing that Elastic Beanstalk failed to destroy
before it timed out. The reason that it failed to destroy was that
the destroy operation was silently ignoring an error on the Elastic
Beanstalk Application - reporting that it could not be destroyed
because there was still an Elastic Beanstalk Application Version
attached to it.

This change fixes the Terraform code so that this error is reported
when if the delete happens.

Commonly we were seeing that Elastic Beanstalk failed to destroy
before it timed out. The reason that it failed to destroy was that
the destroy operation was silently ignoring an error on the Elastic
Beanstalk Application - reporting that it could not be destroyed
because there was still an Elastic Beanstalk Application Version
attached to it.

This change fixes the Terraform code so that this error is reported
when if the delete happens.
@radeksimko radeksimko added the bug Addresses a defect in current functionality. label Oct 27, 2017
Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sending the bugfix! 👍
This looks good.

Just to clarify - it's not changing the behaviour in the sense that Terraform will still error out, just before the 10min timeout and with better/correct error.

i.e. we're not trying to fix any eventual consistency issues here - right?

@radeksimko radeksimko merged commit a142585 into hashicorp:master Oct 30, 2017
@charles-at-geospock
Copy link
Contributor

That's correct - what was happening previously would be that it would...

  • Try to destroy the elastic beanstalk application
  • Get an error back to say that there was an application version still present.
  • Ignore the error (this is thing fixed in this change)
  • Repeatedly call 'Is the application still there?'.
  • Timeout because the application is still there - the request to destroy it failed, so of course it's still there.

Now, at the 'ignore the error' we'll report the error that the application version is present and will stop without the timeout being triggered :-)

The reason we were seeing the problem at all was that we had a configuration issue in our .tf modules that meant that the application version was being referred to with a application name of "${var.application_name}", rather than "${aws_elasticsearch_application.our_app.name}" - and that meant that the two were not dependant on one another, and thus the application could be destroyed before the application version. If we'd got our dependencies right, we would not have seen this problem. It probably won't affect most people, although if they were to manually create more application versions they would get a timeout every time they tried to destroy it.

Thank you for the merge; it will make our lives a lot easier - despite the fact that we've now fixed our dependencies :-)

@ghost
Copy link

ghost commented Apr 10, 2020

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

@ghost ghost locked and limited conversation to collaborators Apr 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants