Upgrading from 3.x to 4.x without replacing ASGs is not possible; workarounds?

[danielkza]

Description

I'm looking to upgrade usages of version 3.x module in my company to 4.x so we can use some of the new features (for example, multiple initial lifecycle hooks). Unfortunately the upgrade process is unnecessarily risky; the documentation claims simply re-creating ASGs should be okay, but in practice is not. Introducing such risk to services running in production, or that are stateful, is a non-starter.

Versions

• Terraform: 0.13, not relevant
• Provider(s): AWS, not relevant
• Module: irrelevant

Reproduction

Create any autoscaling group with any version of this module before 4.0.0. Upgrade to 4.0.0 and run plan. You will see something like:

# module.whatever.aws_autoscaling_group.this[0] will be created
  + resource "aws_autoscaling_group" "this" {
...
# module.whatever.aws_autoscaling_group.this_with_initial_lifecycle_hook[0] will be destroyed
  - resource "aws_autoscaling_group" "this_with_initial_lifecycle_hook" {

The this_with_initial_lifecycle_hook resource has been renamed to this. Which makes sense, but wrecks havoc in any sane upgrade path.

Expected behaviour

Some upgrade path is provided that does not involve ASG recreation. I understand the desire to leave legacy behind, but I fear many setups will be stuck in 3.x indefinitely if there is no possible solution.

Possible solutions

• Use terraform state mv to rename existing resources. This should work, but is error-prone, manual, and not easily reversible.
• Make it possible to use the old resource names somehow. I am not a TF expert, so I am not sure if this is feasible given interpolating resource names is usually not a thing.

[bryantbiggs]

hi @danielkza - the comment on "re-creating ASGs" does not intend to dictate to users how they re-create their autoscaling groups. typically in this situation, I would recommend bringing up a new autoscaling group alongside the existing, perform any testing/validation, and then cut traffic over to this new ASG. you may choose to leave the prior ASG running for some time until you are comfortable with the new solution before removing.

in addition, you can perform terraform state mv safely by either first taking a backup copy of your statefile or if you use something like S3 for your remote backend, you can enable versioning for backup copies.

unfortunately we are unable to provide clean, easy, safe upgrade paths for all breaking changes; its just the nature of these types of changes as we try to move the modules forward. either way, the upgrades are completely optional for users depending on what set of functionality you are looking for

[github-actions[bot]]

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.