-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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_instance diff mismatch when tags drift #1752
Comments
Hi there - great to hear that TF is up and running on Eucalyptus! Here's the relevant bit:
Looks like something to do with tags. Does the config you're using for this instance set any tags? If you change whether it sets tags does that change the problem? If you can include a config snippet that generates the error that would be helpful. |
Thanks for quick response. The config is below: provider "aws" {
access_key = ""
secret_key = ""
region = "eucalyptus"
}
resource "aws_instance" "example" {
ami = "emi-a702b3b6"
instance_type = "m1.large"
} |
@jeevanullas I'm curious - if you add tags to the instance declaration - do you get the same error? Also, are you using 0.4.2 here? Do you have the ability to try out a build from master? https://github.com/hashicorp/terraform/blob/master/CONTRIBUTING.md#setting-up-go-to-work-on-terraform |
Hi @phinze apologies for the delay. I tried with a custom tag in my declaration and it worked like a charm. This was my config: provider "aws" {
access_key = ""
secret_key = ""
region = "eucalyptus"
}
resource "aws_instance" "example" {
ami = "emi-d1a30feb"
instance_type = "m1.large"
tags {
Name = "myinstance"
}
}
I saw that in the case of failure I had a tag on the instance , this was the output of terraform show after I modified the config:
I wonder if this creates problem? Note that on Eucalyptus when you launch an instance the system creates a tag and and assign a value to it. The tag 'euca:node' has a value set to the IP address of the machine running the instance. In case of the successful the plan was
Looks like we cannot have tags.# = 0? Please let me know if you have any further questions. Thanks again for all your assistance. Cheers, |
Yup this was my hunch - it seems like Eucalyptus creates an implicit tag ( |
I've reproduced this on AWS as well.
provider "aws" {
region="us-west-2"
}
resource "aws_instance" "nat" {
ami = "ami-21f78e11"
instance_type = "t1.micro"
}
provider "aws" {
region="us-west-2"
}
resource "aws_instance" "nat" {
ami = "ami-dfc39aef"
instance_type = "t2.micro"
}
$ plan
Refreshing Terraform state prior to plan...
aws_instance.nat: Refreshing state... (ID: i-1dc318ea)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.
Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.
Path: create.tfplan
-/+ aws_instance.nat
ami: "ami-21f78e11" => "ami-dfc39aef" (forces new resource)
availability_zone: "us-west-2b" => "<computed>"
ebs_block_device.#: "0" => "<computed>"
ephemeral_block_device.#: "0" => "<computed>"
instance_type: "t1.micro" => "t2.micro" (forces new resource)
key_name: "" => "<computed>"
placement_group: "" => "<computed>"
private_dns: "ip-172-31-30-19.us-west-2.compute.internal" => "<computed>"
private_ip: "172.31.30.19" => "<computed>"
public_dns: "ec2-52-24-125-143.us-west-2.compute.amazonaws.com" => "<computed>"
public_ip: "52.24.125.143" => "<computed>"
root_block_device.#: "1" => "<computed>"
security_groups.#: "0" => "<computed>"
subnet_id: "subnet-b4b122d1" => "<computed>"
tags.#: "1" => "0"
tags.nerg: "dorb" => ""
tenancy: "default" => "<computed>"
vpc_security_group_ids.#: "1" => "<computed>"
* 1 error(s) occurred:
* aws_instance.nat: diffs didn't match during apply. This is a bug with Terraform and should be reported. |
fixes #1752 Includes AccTest reproducing example from the issue as well as a bunch of explanatory comments in the tests and impls.
fixes #1752 Includes AccTest reproducing example from the issue as well as a bunch of explanatory comments in the tests and impls.
fixes hashicorp#1752 Includes AccTest reproducing example from the issue as well as a bunch of explanatory comments in the tests and impls.
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. |
Hi guys,
Great stuff. We got terraform going on Eucalyptus. Tried to change a plan by changing the EMI (AMI) ID and applying it. Found a problem. Logs at
https://gist.github.com/jeevanullas/e15beaa8c4879acc7e6e
If I apply the plan again now, it does create a new instance with the new EMI ID. Thanks for looking at it.
Cheers,
Deependra
The text was updated successfully, but these errors were encountered: