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

Instance tags are not applied to new AWS instances in Gov & China #14535

Closed
joelittlejohn opened this issue May 16, 2017 · 10 comments · Fixed by #14627
Closed

Instance tags are not applied to new AWS instances in Gov & China #14535

joelittlejohn opened this issue May 16, 2017 · 10 comments · Fixed by #14627
Assignees

Comments

@joelittlejohn
Copy link

joelittlejohn commented May 16, 2017

Terraform Version

0.9.5

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

resource "aws_instance" "elasticsearch" {
  count                   = "${var.nodes}"
  ami                     = "${var.ami}"
  disable_api_termination = false
  instance_type           = "${var.instance_type}"
  iam_instance_profile    = "${aws_iam_instance_profile.elasticsearch.name}"
  subnet_id               = "${element(var.subnet_ids, count.index)}"
  vpc_security_group_ids  = ["${var.security_group_id}", "${aws_security_group.elasticsearch.id}"]
  key_name                = "${var.key_pair}"

  root_block_device {
    volume_size           = "8"
    volume_type           = "gp2"
  }

  tags {
    Name = "elasticsearch-${var.name}-${count.index}"
    Application = "elasticsearch-${var.name}"
  }
}

Expected Behavior

Instance should have been created with 2 tags, as shown in the configuration.

Actual Behavior

The instance was created with no tags. terraform plan then showed that these three tags needed to be added, and a second terraform apply added the tags. So in short, I had to run terraform apply twice to end up with an instance that was tagged correctly.

Steps to Reproduce

  1. Create a new aws_instance configuraiton that includes some tags
  2. terraform apply -target module.mymodule - notice that the tags are not present
  3. terraform plan -target module.mymodule - notice that the tag changes are shown
  4. terraform apply -target module.mymodule - notice that the tags are now present

References

I suspect this may have something to do with #13173 and/or #14019.

@joelittlejohn joelittlejohn changed the title Instance tags are not applied to new instances Instance tags are not applied to new AWS instances May 16, 2017
@joelittlejohn
Copy link
Author

This is a serious one I think.

Terraform completes its operations and runs successfully but leaves instances untagged. Any discovery mechanism that relies on tags will not work, but of course terraform may have destroyed a working configuration as part of its operations.

Any orchestration tools using terraform will assume that a single call to terraform apply that succeeds will have converged the system towards the new configuration correctly and these may also proceed to destroy older resources even though the new system is not tagged correctly.

I'm happy to provide more info if anyone is having trouble replicating this.

Thanks!

@stack72
Copy link
Contributor

stack72 commented May 17, 2017

Hi @joelittlejohn

So, I have spent some time looking into this. From what I can see, we now use a different API call when we initially create instances with Terraform and create tags. This is part of the new TagSpecifications when running instances. We can see this is the case as when you apply terraform a second time, it creates the tags. Tag updates are controlled via a different part of the AWS API

Can you give me some idea of what the IAM user policy you are running looks like? I suspect that this is an IAM policy issue but want to confirm this is the case

Thanks

Paul

@joelittlejohn
Copy link
Author

Yeah, it's a little surprising but my guess was that this was either a problem in the way the TagSpecification was built, or that this was an actual bug in the AWS Go SDK (at least the version of it that Terraform is using).

I'm running terraform as an admin, that is, I'm using the IAM managed policy 'AdministratorAccess' that gives full access to all services.

@stack72
Copy link
Contributor

stack72 commented May 17, 2017

So it's not a bug IMO - we have a lot of tests running for this right now that pass each night. I will continue to look into it

Paul

@joelittlejohn
Copy link
Author

One other thing I'm going to look into tonight:

So far I've only been seeing this in cn-north-1. Haven't actually tried this in a more typical region like eu-west-1.

@stack72
Copy link
Contributor

stack72 commented May 17, 2017

@joelittlejohn yes, this will not work in china or gov - we have a note listed in the last changelog about this exact thing :(

@joelittlejohn
Copy link
Author

joelittlejohn commented May 17, 2017 via email

stack72 added a commit that referenced this issue May 18, 2017
…China

Fixes: #14535

When in a `restricted` cloud, we should fall back to the old method of
tagging. Before this change we saw the following:

```
% terraform apply                                                                                                                                                                                         ✭
aws_instance.foo: Creating...
  ami:                          "" => "ami-0fa3c42c"
  associate_public_ip_address:  "" => "<computed>"
  availability_zone:            "" => "<computed>"
  ebs_block_device.#:           "" => "<computed>"
  ephemeral_block_device.#:     "" => "<computed>"
  instance_state:               "" => "<computed>"
  instance_type:                "" => "m1.small"
  ipv6_address_count:           "" => "<computed>"
  ipv6_addresses.#:             "" => "<computed>"
  key_name:                     "" => "<computed>"
  network_interface.#:          "" => "<computed>"
  network_interface_id:         "" => "<computed>"
  placement_group:              "" => "<computed>"
  primary_network_interface_id: "" => "<computed>"
  private_dns:                  "" => "<computed>"
  private_ip:                   "" => "<computed>"
  public_dns:                   "" => "<computed>"
  public_ip:                    "" => "<computed>"
  root_block_device.#:          "" => "<computed>"
  security_groups.#:            "" => "<computed>"
  source_dest_check:            "" => "true"
  subnet_id:                    "" => "<computed>"
  tags.%:                       "" => "1"
  tags.foo:                     "" => "bar"
  tenancy:                      "" => "<computed>"
  volume_tags.%:                "" => "<computed>"
  vpc_security_group_ids.#:     "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-0009f227ae24791b9)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

% terraform plan                                                                                                                                                                                          ✭
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_instance.foo: Refreshing state... (ID: i-0009f227ae24791b9)
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. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ aws_instance.foo
    tags.%:   "0" => "1"
    tags.foo: "" => "bar"

Plan: 0 to add, 1 to change, 0 to destroy.
```

After this patch, we see the following:

```
% terraform apply                                                                                                                                                                                       ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-provider.
  If you did not expect to see this message you will need to remove the old plugin.
  See https://www.terraform.io/docs/internals/internal-plugins.html
aws_instance.foo: Creating...
  ami:                          "" => "ami-0fa3c42c"
  associate_public_ip_address:  "" => "<computed>"
  availability_zone:            "" => "<computed>"
  ebs_block_device.#:           "" => "<computed>"
  ephemeral_block_device.#:     "" => "<computed>"
  instance_state:               "" => "<computed>"
  instance_type:                "" => "m1.small"
  ipv6_address_count:           "" => "<computed>"
  ipv6_addresses.#:             "" => "<computed>"
  key_name:                     "" => "<computed>"
  network_interface.#:          "" => "<computed>"
  network_interface_id:         "" => "<computed>"
  placement_group:              "" => "<computed>"
  primary_network_interface_id: "" => "<computed>"
  private_dns:                  "" => "<computed>"
  private_ip:                   "" => "<computed>"
  public_dns:                   "" => "<computed>"
  public_ip:                    "" => "<computed>"
  root_block_device.#:          "" => "<computed>"
  security_groups.#:            "" => "<computed>"
  source_dest_check:            "" => "true"
  subnet_id:                    "" => "<computed>"
  tags.%:                       "" => "1"
  tags.foo:                     "" => "bar"
  tenancy:                      "" => "<computed>"
  volume_tags.%:                "" => "<computed>"
  vpc_security_group_ids.#:     "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-04cd122e28f167a14)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

% terraform plan                                                                                                                                                                                        ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-provider.
  If you did not expect to see this message you will need to remove the old plugin.
  See https://www.terraform.io/docs/internals/internal-plugins.html
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_instance.foo: Refreshing state... (ID: i-04cd122e28f167a14)
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```
@stack72
Copy link
Contributor

stack72 commented May 18, 2017

Hi @joelittlejohn

Using our Gov cloud account, I found the bug - patch incoming :)

Paul

stack72 added a commit that referenced this issue May 18, 2017
…China (#14627)

Fixes: #14535

When in a `restricted` cloud, we should fall back to the old method of
tagging. Before this change we saw the following:

```
% terraform apply                                                                                                                                                                                         ✭
aws_instance.foo: Creating...
  ami:                          "" => "ami-0fa3c42c"
  associate_public_ip_address:  "" => "<computed>"
  availability_zone:            "" => "<computed>"
  ebs_block_device.#:           "" => "<computed>"
  ephemeral_block_device.#:     "" => "<computed>"
  instance_state:               "" => "<computed>"
  instance_type:                "" => "m1.small"
  ipv6_address_count:           "" => "<computed>"
  ipv6_addresses.#:             "" => "<computed>"
  key_name:                     "" => "<computed>"
  network_interface.#:          "" => "<computed>"
  network_interface_id:         "" => "<computed>"
  placement_group:              "" => "<computed>"
  primary_network_interface_id: "" => "<computed>"
  private_dns:                  "" => "<computed>"
  private_ip:                   "" => "<computed>"
  public_dns:                   "" => "<computed>"
  public_ip:                    "" => "<computed>"
  root_block_device.#:          "" => "<computed>"
  security_groups.#:            "" => "<computed>"
  source_dest_check:            "" => "true"
  subnet_id:                    "" => "<computed>"
  tags.%:                       "" => "1"
  tags.foo:                     "" => "bar"
  tenancy:                      "" => "<computed>"
  volume_tags.%:                "" => "<computed>"
  vpc_security_group_ids.#:     "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-0009f227ae24791b9)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

% terraform plan                                                                                                                                                                                          ✭
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_instance.foo: Refreshing state... (ID: i-0009f227ae24791b9)
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. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ aws_instance.foo
    tags.%:   "0" => "1"
    tags.foo: "" => "bar"

Plan: 0 to add, 1 to change, 0 to destroy.
```

After this patch, we see the following:

```
% terraform apply                                                                                                                                                                                       ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-provider.
  If you did not expect to see this message you will need to remove the old plugin.
  See https://www.terraform.io/docs/internals/internal-plugins.html
aws_instance.foo: Creating...
  ami:                          "" => "ami-0fa3c42c"
  associate_public_ip_address:  "" => "<computed>"
  availability_zone:            "" => "<computed>"
  ebs_block_device.#:           "" => "<computed>"
  ephemeral_block_device.#:     "" => "<computed>"
  instance_state:               "" => "<computed>"
  instance_type:                "" => "m1.small"
  ipv6_address_count:           "" => "<computed>"
  ipv6_addresses.#:             "" => "<computed>"
  key_name:                     "" => "<computed>"
  network_interface.#:          "" => "<computed>"
  network_interface_id:         "" => "<computed>"
  placement_group:              "" => "<computed>"
  primary_network_interface_id: "" => "<computed>"
  private_dns:                  "" => "<computed>"
  private_ip:                   "" => "<computed>"
  public_dns:                   "" => "<computed>"
  public_ip:                    "" => "<computed>"
  root_block_device.#:          "" => "<computed>"
  security_groups.#:            "" => "<computed>"
  source_dest_check:            "" => "true"
  subnet_id:                    "" => "<computed>"
  tags.%:                       "" => "1"
  tags.foo:                     "" => "bar"
  tenancy:                      "" => "<computed>"
  volume_tags.%:                "" => "<computed>"
  vpc_security_group_ids.#:     "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-04cd122e28f167a14)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

% terraform plan                                                                                                                                                                                        ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-provider.
  If you did not expect to see this message you will need to remove the old plugin.
  See https://www.terraform.io/docs/internals/internal-plugins.html
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_instance.foo: Refreshing state... (ID: i-04cd122e28f167a14)
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```
@joelittlejohn
Copy link
Author

@stack72 Wow, fantastic! Thanks for jumping on this so quickly.

@joelittlejohn joelittlejohn changed the title Instance tags are not applied to new AWS instances Instance tags are not applied to new AWS instances in Gov & China May 18, 2017
@ghost
Copy link

ghost commented Apr 12, 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 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants