Terraform-provider-aws: Changing root_block_device.volume_size forces new resource (aws_instance)

[hashibot]

_This issue was originally opened by @cweagans as hashicorp/terraform#14445. It was migrated here as part of the provider split. The original body of the issue is below._

---

Terraform Version

v0.9.5

Affected Resource(s)

• aws_instance

Terraform Configuration Files

Before:

provider "aws" {
  region = "us-east-1"
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
  }

  filter {
    name = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"]
}

resource "aws_instance" "test_instance" {
  ami = "${data.aws_ami.ubuntu.id}"
  instance_type = "t2.micro"

  tags {
    Name = "cweagans-test-instance"
  }
}

After:

provider "aws" {
  region = "us-east-1"
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
  }

  filter {
    name = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"]
}

resource "aws_instance" "test_instance" {
  ami = "${data.aws_ami.ubuntu.id}"
  instance_type = "t2.micro"

  tags {
    Name = "cweagans-test-instance"
  }

  root_block_device {
    volume_size = "100"
  }
}

Expected Behavior

Root volume should have been resized from the default 8GB to 100GB without deleting the instance in the process.

Actual Behavior

The instance was deleted and recreated.

Steps to Reproduce

terraform apply the first config above, change config to the second one, and terraform apply again.

[marek-obuchowicz]

Is there anything preventing this patch from go live? Seems like it's stuck since half a year

[bflad]

It looks like the original author of #1396 hasn't implemented review feedback. I'll ping them once more.

[daniilyar]

Guys, this still reproduces on Terraform v0.11.7, aws provider v1.26.0.
It also reproduces when you increase the size for already existing 'root_block_device' block.

Being a DevOps Lead, I see day by day how tens of people resize the root volume manually in AWS Console first and then do a 'backward compatibility' update in Terraform config each time when they need to increase the root volume. With non-root volume attachments Terraform has the other scalability issue, but it is harder to resolve, so it would be very nice to solve it first for a 'low hanging fruit', i.e. for root volumes.

Any ideas when this super-desired feature may be added?

I'd say this issue is a real blocker for proper IaC on small AWS projects with Terraform.
It actually costs my small company ~50$ / mo because of the overspent time of DevOps engineers who are forced to do some UI actions to resize volumes instead of just triggering the automation.

So I am ready to put 50$ bounty or provide some cloud resources for your project (spinned by Terraform, haha) for free if this issue get's fixed and added to the stable version.

We are not Go professionals, but maybe we can also help somehow to speed it up?

[majormoses]

@daniilyar I share your pain and would like to see this solved.

Long story short:

1. For Linux instances AWS supports increasing root volume safely without re-attaching it, but only for new-generation instances (which are already >70%+ of the current AWS instances amount and keeps increasing).
2. For Windows instances AWS supports increasing root volume safely without re-attaching it for any instance type.

So, I believe that the proper fix for this one is to teach Terraform AWS provider to understand if it provisions the old generation instance or not. If it provisions the new-generation one, then it can modify volume in-place. Otherwise volume should be reattached on a stopped instance.

As I have previously commented here: https://github.com/hashicorp/terraform/issues/14445#issuecomment-301600277 I would not be comfortable with the machine stopping/rebooting in order to resize the volume the plan needs to be as simple as safe/unsafe because terraform lacks the context to know whats on the box beyond the resources provisioned.

I would be in favor of providing some detection to see if it is capable of resizing and if so doing a modification and if not it would keep the existing behavior.

new-generation instances

Can you provide a bit more detail on what that specially means? Such as VPC vs classic? Or are we looking at needing to maintain a mapping of each family names and check (using m as example with purely pseudo code) if instance_family.noop? && current.instance_family == 'm' && current.instanze_size.split('.')[1] >= 3? While I am not a go developer understanding what needs to be done is language agnostic and I'd be happy to look into how to detect this and write up a POC in ruby/python if I know what I am looking for.

[marek-obuchowicz]

If autodetection would be complicated and slow down development - we could even live with manual flag specifying which volume resize scenario should be applied. But please let us have at least some solution to for that basic/common task available soon...

[7rack]

volume_type change also cause instance deleted and recreated.

[hashibot[bot]]

This has been released in version 2.58.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

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