-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
aws_autoscaling_group in deposed state, but shouldn't be #11459
Comments
See #10753 for more details on what deposed means. Deposed only happens if you attempted a create before destroy apply earlier (that's how it shifts to "deposed"). Further, if a CBD resource depends on that ASG, it'll automatically make that resource CBD and cause deposition. As #10753 states correctly though: we need to do a way better job documenting this! Sorry! |
@mitchellh Thanks for your reply and my apologies for what appears to all be the same issue. I know that I want to keep the machines associated with the ASG id above. Will the ASG and thus the associated machines be deleted or not when I would run If the answer is "yes", how can I get a tfstate file which does meet my expectations, which is that everything is fine and nothing needs to happen? |
If it is deposed then the ASG and associated machines likely will. You can move the "deposed" instance into the "primary" slot in the state. The This is a strange state to get in though and one I haven't experienced before [in the community]. It'd help to understand how this happened and maybe we can build guardrails to prevent this in the future. |
Note if you back up your state file and never run |
@mitchellh Create an ASG with a health check which fails, then it times out after 10 minutes and you get into this state. That's the only weird thing I did, at least. |
Yes, that makes sense: if you have create before destroy, and the new creation fails, your old one is "deposed" (cause it was going to be destroyed anyways due to CBD) .You can see that from the explanation in #10753. That is the correct behavior for CBD. "Deposed" is just a state that instances go between the create and destroy. |
@mitchellh I don't want this resource to be destroyed and I would like it to work like Terraform expects it to work, but I am confused at this moment. Will something else be created first, before this is destroyed? It's really not clear what Terraform's plan is supposed to communicate to me in this case. Before 0.8 there was no such communication problem. |
Yes, if CBD is set, a new ASG is created first, Terraform [by default] will wait for instances to populate that ASG, and then the old one will be destroyed. Note that even if you don't set CBD on the ASG, if any dependent (child) resource depends on the ASG has CBD and requires CBD, the ASG will "inherit" the CBD. Its hard to explain why that is necesasry, but if you manually sketch out how to do a CBD safely you'll see that that is necessary. |
@mitchellh In this case there is the difficulty that I run ECS containers which are supposed to first scale up (with the new machines created by the new ASG), but currently no new ECS containers are being launched, because the desired (not the maximum number) has already been deployed. This creates a "no progress"-situation. Do you have any suggestion how to get around this? |
I think one use case to consider:
EDIT: I think this is the workflow that got me into this situation anyway:
|
I'd offer that a manual action you've stated across a few different bugs [*] is the root cause of the undesired behavior you're observing: In #11459 (comment)
Summary of the references below:
|
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. |
The following applies to Terraform v0.8.5-dev (cb4ffd4+CHANGES)
My understanding of "deposed" is that it's a resource which will be deleted if one does a subsequent
terraform apply
, which would be a huge problem.In the terraform.tfstate file, I see the autoscaling group with a particular ID with the deposed state:
If I compare the id with the one that should remain in the AWS Console, I see that they match, so it shouldn't be deleted.
Relevant: #10753
The text was updated successfully, but these errors were encountered: