Destruction of worker ASG blocked by protect_from_scale_in = true

[b2cbre]

I have issues

Unable to destroy a worker ASG or the cluster because of protect_from_scale_in = true. This of course can be changed but that is generally undesirable because one expects that if you can create it you can also destroy it without changing the configuration. :)

I'm willing to assist with work on this but figured I'd open a ticket in case someone had thoughts on how to resolve this without making a PR and without changing protect_from_scale_in to false when we want to destroy or recreate a worker ASG.

I'm submitting a...

• bug report
• feature request
• support request - read the FAQ first!
• kudos, thank you, warm fuzzy

What is the current behavior?

Unable to destroy a worker ASG due to:

Error: Error draining autoscaling group: Group still has 1 instances

AWS console shows on the ASG activity history:

Could not scale to desired capacity because all remaining instances are protected from scale-in.

If this is a bug, how to reproduce? Please include a code sample if relevant.

Set protect_from_scale_in to true on this repo, create a cluster, then try to destroy it with terraform destroy.

What's the expected behavior?

Destruction without code change or updating protect_from_scale_in.

Are you able to fix this problem and submit a PR? Link here if you have already.

Environment details

• Affected module version: commit 49b0667
• OS: linux
• Terraform version: 0.12.24

Any other relevant info

None that I can think of at this time.

[max-rocket-internet]

It defaults to false so I don't get the problem? If you want to destroy without issues then don't set it to true?

[b2cbre]

It defaults to false so I don't get the problem? If you want to destroy without issues then don't set it to true?

Thank you for considering this with me. My intent in opening this issue is not to attack but to discuss.

I suppose I missed where this behavior is documented in the module for this feature. Where may I find that? When digging into this it seems this variable is directly passed to the provider so perhaps that is where I missed the importance of checking the provider's documentation on the keys in workers_group_defaults and workers_group_defaults_defaults. Perhaps it is profitable for that connection to be noted in the README, FAQ, or comments of local.tf.

If the problem is that I opened a ticket after changing defaults then why was #812 not treated the same way?

Contributing guidelines are where? I'd rather not create problems but contribute to solutions. The readme says "Full contributing guidelines are covered here." which links to https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/CONTRIBUTING.md which is a 404 in my experience and I don't see a CONTRIBUTING.md in /.

[dpiddockcmp]

#812 was a bug in the module caused by a lack of dependency ordering. It was a simple fix.

This issue is about an AWS feature and emergent behaviour of the terraform AWS provider, not something the module can fix.

This issue has come up at least a couple times before:

• fails to destroy asg #176
• Destroy fails when protect_from_scale_in = true #288

There is an open issue against the provider: hashicorp/terraform-provider-aws#5278

[b2cbre]

Awesome! Closing this cause it's pointless to have a duplicate issue.

Thank you, I completely forgot to search existing issues (closed and open).

[max-rocket-internet]

Thank you for considering this with me. My intent in opening this issue is not to attack but to discuss.

We are all here to discuss, don't worry 💛

There is an open issue against the provider: hashicorp/terraform-provider-aws#5278

This I was not aware of. Interesting. Thanks @dpiddockcmp

[github-actions]

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.