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

Downgrading ec2 instance type from t2.small to t2.micro "forces new resource" #9157

Closed
jleclanche opened this issue Sep 30, 2016 · 6 comments · Fixed by #11998
Closed

Downgrading ec2 instance type from t2.small to t2.micro "forces new resource" #9157

jleclanche opened this issue Sep 30, 2016 · 6 comments · Fixed by #11998

Comments

@jleclanche
Copy link

jleclanche commented Sep 30, 2016

Terraform Version

Terraform v0.7.4

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

resource "aws_instance" "hsreplaynet_web_01" {
    ami = "${lookup(var.amis, var.region)}"
    instance_type = "t2.small"
    key_name = "${aws_key_pair.hsreplay_provisioner_auth.id}"
    security_groups = ["${var.prod_security_group_name}"]
    tags {
        name = "hsreplaynet_web_01"
        class = "hsreplaynet"
    }
}

Downgrading the instance_type will force a new resource. Upgrading it however, will not. I have seen this on several different instance types such as t2.small, t2.large, m4.xlarge and m4.2xlarge.

I have also verified that I was able to manually go in the AWS console, stop the instance, downgrade it and restart the instance without having to recreate it.

@apparentlymart
Copy link
Contributor

Hi @jleclanche!

Currently Terraform doesn't have a way to model actions that require temporarily stopping an instance. This is being discussed over in #1579. I think robust support for managing the multi-step process of stopping, altering and re-starting will be a pre-requisite for this, though this would definitely be a great additional feature to support once that's in place.

@jleclanche
Copy link
Author

@apparentlymart Are we talking about the same thing? Terraform does support upgrading the instance, which has the exact same prerequisite (stopping and then restarting the instance). Or am I missing something?

@apparentlymart
Copy link
Contributor

If by "upgrading" you mean replacing instance_type with another value that is somehow "bigger" than the current value, I am not aware that Terraform is able to do that without destroying the image. Are you sure that's true? A quick check of the code suggests to me that any change to instance_type will "force new resource", regardless of what direction you're changing it.

I think I must not be understanding what you are asking about here... could you perhaps show an example output of terraform plan for the "upgrade" and "downgrade" actions you're talking about, so I can understand precisely what configuration changes you're thinking of?

@jleclanche
Copy link
Author

This is the weirdest thing. I'm changing a m4.large to m4.2xlarge and now I do see "forces new resource". But I can promise you that I ran that upgrade before, and it didn't force a new resource. In fact, I might even be able to dig the terraform plan files on Jenkins as I keep those around for some time.

But yes, you got it, that's what I've been seeing: instance_type "upgrades" are fine, but downgrades force a new resource. Although now I'm seeing downgrades everywhere. Hrm.

Also worth noting I don't see this "forces new resource" problem on RDS instances at all.

@FlorinAndrei
Copy link

Terraform devs: Please keep this issue open until TF can properly handle stop/start/restart of instances - as described in #1579 and similar.

Once we can stop/start instances, then changing the instance type (or size) without destroy/recreate should be easy to handle from within Terraform.

stack72 added a commit that referenced this issue Feb 16, 2017
new instance

Fixes: #9157

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_changeInstanceType'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/16 15:13:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_changeInstanceType -timeout 120m
=== RUN   TestAccAWSInstance_changeInstanceType
--- PASS: TestAccAWSInstance_changeInstanceType (303.85s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	303.876s
```
stack72 added a commit that referenced this issue Feb 16, 2017
new instance

Fixes: #9157

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_changeInstanceType'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/16 15:13:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_changeInstanceType -timeout 120m
=== RUN   TestAccAWSInstance_changeInstanceType
--- PASS: TestAccAWSInstance_changeInstanceType (303.85s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	303.876s
```
stack72 added a commit that referenced this issue Feb 16, 2017
new instance

Fixes: #9157

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_changeInstanceType'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/16 15:13:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_changeInstanceType -timeout 120m
=== RUN   TestAccAWSInstance_changeInstanceType
--- PASS: TestAccAWSInstance_changeInstanceType (303.85s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	303.876s
```
stack72 added a commit that referenced this issue Feb 16, 2017
new instance

Fixes: #9157

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_changeInstanceType'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/16 15:13:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_changeInstanceType -timeout 120m
=== RUN   TestAccAWSInstance_changeInstanceType
--- PASS: TestAccAWSInstance_changeInstanceType (303.85s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	303.876s
```
stack72 added a commit that referenced this issue Feb 16, 2017
…#11998)

new instance

Fixes: #9157

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_changeInstanceType'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/16 15:13:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_changeInstanceType -timeout 120m
=== RUN   TestAccAWSInstance_changeInstanceType
--- PASS: TestAccAWSInstance_changeInstanceType (303.85s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	303.876s
```
stack72 added a commit that referenced this issue Feb 16, 2017
…#11998)

new instance

Fixes: #9157

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_changeInstanceType'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/02/16 15:13:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_changeInstanceType -timeout 120m
=== RUN   TestAccAWSInstance_changeInstanceType
--- PASS: TestAccAWSInstance_changeInstanceType (303.85s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	303.876s
```
@ghost
Copy link

ghost commented Apr 16, 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 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.

@ghost ghost locked and limited conversation to collaborators Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants